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ABSTRACT 


This. research discusses a program which alds the 
user of an automatic programming system (APS) In the 
“debugging” of hts model of his problem situation. In 
essence, the user must make sure that he and the APS mean. 
the same thing by the description of the problem which the 
APS Is to solve. The problem domatn considered fn this 
thesis is that of “business games” (T.e., the management 
sitmulatton games which are used as a learning tool in the 
study of management). <A language for describing models of 
these games fs presented. The paper then describes the 
program's methods of stmulating and finding bugs In models 
written In thks Tanguage. Important aspects of the program's 
problem-solving approach to debugging are [ts internal 
knowledge of "bugs" and of user Intention within the model. 
This. Internal knowledge stresses the [mportance of bugs 
arising from the Interaction of submodels within. the model. 
Some detalls of the program's Implementation (in the 
Conntver language ) are discussed, The necessity of 
“model -debuggting”™ In automatic programming Is emphasized. 
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1 Jntroduction 


The purpose of this research Is to 
explore a methodology for debugging certain models of real 
world sftuatlons. The models considered here consist of 
groups of well-defined submodels. The submodels themselves 
are falrly structured; the Interaction between submodels Is 
not, In this paper | will discuss a program which uses the 
techniques of goal-programming to explore the’ Interactive 
behavior of a given model. The basic fdea is that a bug in 
the model will give rise to a "problem". The program then 
tries to solve this problem in an environment defined and 
constrained by the model. Those steps at which the 
program's problem-solving process encounters constraints 
caused by unintended tInteraction of submodels suggest 
possible locations of bugs within the model. 

To a large extent, the problems of this 
research are "artifictal Intelligence" problems. That Is, 
the research problems Involve representation of knowledge in 
a form which is useful to the problem-solver, and 
representation of the problem-solving process as a computer 
program, The remainder of this paper will deal with one 
solution of these problems for a program which debugs models 


of management sItuattons. This section will noresent a more 
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complete explanation of the area of model-debugging as ! see 
it. The next section provides an overview of the whole 
debugging process tn the context of a detalled example. 
Later sections develop some Ideas about bugs, 
problem-solving, goal-programming, and the program Itself. 


1.1 Define "define" 


1.1.1 What Is a model? 


Marvin Minsky describes the concept of a 
"model" as follows: 


If a creature can answer a question 
about a hypothetical experiment without actually 
performing tt, then {ft has demonstrated some 
knowledge about the world. For his answer to the 
questton must be an encoded description of the 
behavior (Instde the creature) of a sub-machine or 
"model" responding to an encoded deseription of 
the world situation described by the question. 

We use the term "model" In the following 
sense: to an observer B, an object A* Is a model 
of an object A to the extent that B can use A* to 
answer questions that [Interest him about A. [12] 


For the purpose of this research, the term "model" will be 
used In a much less general and more concrete way. 
Specifically, the program discussed here requires that the 
“encoded description" be of a particular pre-defined type, 
that the kinds of world-objects "A" to be modelled belong to 


a very limited class of things, and that "B"'s questions of 
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Interest be sharply restricted, 

After this section, the term "model" 
will be used to refer to a user-defined collection of 
constructs In a mode] specification language (MSL) 
(presented In section 4.1) which deserfbes a "real-world" 
management system. (1) For now, suffice [ft to say that a 
"model" ts a user's description of his system of Interest. 
That fs, the user thinks that the model describes’ his 


system--actually, the model contatns bugs. 


1.1.2 What is debugging? 


When a model's performance [Is not what 
the user expects, we say that the model has a "bug" (see 
section 3). The process of findine what causes the 
discrepancy between performance and expectation ts called 
"debugging". It Is the nature of complex processes that the 
cause of a discrepancy may be related to the manifestation 
of the discrepancy only through a seemingly tntricate chatn 
of reasoning. The purpose of this research ts to write a 
program which knows the necessary kind of reasoning to g0 


from the manifestation to the cause of a bug. 


(1) 
Actually, a real-world business game. 
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In order to Incorporate this reasoning 
process, the program must have knowledge about MSL models 
(see 4.1), the kinds of bugs that occur In MSL models (see 
3.3), how these bugs manifest themselves (see 4.4.2), and 
how the causes are related to the manifestations (see 
4.4.3), Of course, this Is In some sense the “whole story"; 
before launching Into ft, It might be a good Idea to examine 
our reasons for worrying about model-debugg!ng In the first 


place. 


1.2 The Importance of model-debugging 


1.2.1 Model-debugeing as a universal concept 


The process of gaining knowledge about 
the world Is process of model formatton and debugging. 
The Progress of all organized thought, especlally sctence, 
has often been described in this way. More recently, work 
by psychologists such as Plaget and artificial Intelligence 
researchers such as Seymour Papert has brought. this model 
formation/debugging view to bear on the entire learning 
process. Certainly, no one can doubt the [mportance of 
studying so fundamental a process. | 

Of course, In thts research, the 


viewpoint must be strictly limited, The following sections 
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will describe a process which seems only barely related to 
the grandiose exaltatlons of the previous paragraph, For 
one thing, the extremely close Interaction between model 
debugging and formation wlll be greatly restricted to allow 
examination of the debugging process Itself. Also, the 
restrictions Inherent (1) In the "show a working program" 
approach of this research make the class of problems seem 
trivial when compared to the overall problem of 
model -debugging. 

Although | could now clalm that the 
validity of this research effort Is that It provides an 
Inittal Investigation into a very hatry area (the usual 
Induction step in artifictal Intelll gence theses), | will 
move in more practical directions. (Of course, ! hope for 
the higher parallels all along.) Specifically, | consider 
the [Importance of the kind of model-debugging actually 


presented here for the new field of automatic programming. 


1.2.2 Model-debugginge in automatic programming 


(1) These restrictions are "ftnherent" at this stage of our 
knowledge, at this stage of my knowledge, and in the 
exigencies of churning out a Master's thesis. Certainly, 
there are no Inherent restrictions [tn the capabiltty of 
computers to Incorporate the process, 
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Automatic programming {fs the art of 
providing a computer program (an "automatic programming 
system" (APS)) which takes as Input some _ user-amenable 
description of a task and produces as output computer 
programs to accomplish that task. The user's description of 
his task ts his “model" In the sense described [fn 1.1.1. 
This Is the "model" which the program described In this 
thesis must debug. 

But why worry about model-debugging? 
Why not let the user specify something, let the system 
generate a solution program, and stmply leave ft to the user 
to respecify the problem If he doesn't Ifke the results? 
There are several answers to this question, some obvious, 
others not so obvious. BasIcally, the reasons for providing 
sophisticated model -debuggIng alds revolve around 
considerations of efficient use of the APS, ease of use of 
the APS, ease of construction of the APS, and "safety" In 
the use of the APS. 

The most obvious _— reason for 
model-debuggIng is that  stnce code-generation§ (1.e., 
actually writing the solutlton program after the task 
description Its In) fs a rather arduous. process, It _ Is 
worthwhile making sure that the user and the APS agree on 


what the problem ts before the APS actually writes programs 
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to solve the problem. This idea of pre-code-generation 
debugging ts as old as compllers, and is fairly well 


understood. (1) 


A related but not quite so obvious 
reason for providing model-debugging atds [n an APS Is to 
make the system easfer to use. This ts especlally necessary 
In an APS Itke Protosystem ! [9[ which attempts to provide 
problem-solving expertise to ald the user. The point Is 
that the APS is designed to provide problem-solving 
knowledge for a user who Is not at all adept fn computer 
problem-solving. To help him destgn a description of his 
task and then not to ald him In debugging that description 
seems I}ke providing not much help at all: descriptions of 
complex problems “always” have bugs, and finding them Is 
usually as sophisticated a task as writing the description 
In the first place. (2) Thus, I beleve that an APS that 
does not provide model-debugging ald would be difficult, tf 
not Impossible, to use. 


Supposing, then, that some kind of 


(1) The actual debugging of models may be quite different 
from the debugging of source code, but the reason for dolng 
so Is the same fn this case. 


(2) Statistics have shown that about 50% of the time [fn 
large system development Is spent {In debugging |2|. 
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debugging ald Is necessary, how should {ft be Interfaced with 
the user and with the APS? The answer, |! think, Is that 
debugging should occur when the system's knowledge of the 
user's problem ts still at a high level of symbolic 
description. That Is, prior to code generation. This 
leaves the debugging effort Tn the realm of 
model-debugging. The reason that {It Is Important to keep 
debugging at a high symboltc level fs to keep the destgn of 
the APS as simple as possible. It Is quite difficult to 
maintain the links between mistakes which occur at low 
levels of description (e.g., programs) and their high-level 
causes, Certainly the user cannot be -responsible for 
matntatning these links. If the APS tells him that "an 
I}legal reference was generated from location 11437", we 
cannot expect him to have-any notion of what went wrong with 
his model description. In fact, the construction of an APS 
which could make this connection between the bug's 
mantfestation and Its cause would be extremely difficult. 
It seems much more’ reasonable to carry on debugging at a 
high level of symbol tc description which both the user and 
the APS can understand In terms of the user's model. 
Finally, there ts a very special problem 
which artses In connection with the use of the APS, The 


user begins to develop a dependency on the APS and to trust 
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the results of the solution programs. When the system Is 
more expert then the user (as Is the case [In Protosystem 1), 
the user may even trust results which "common sense" (J.e., 
previous experlence, educated guesses, etc.) tells him are 
wrong. In these circumstances, It Ts of paramount 
Importance that the user be sure that the APS has a correct 
understanding of his model. Other than the model-debugging 
subsystem within the APS, there may be no source of feedback 
which enables the user to find out that there is anything 
wrong at all. (1) 

The model-debugging facility has sole 
responsibility for helping the user to understand what Is 
wrong with his model In terms of the model--i.e., In the 
only terms the user understands. An A®S which does not 
provide a facility for Interactive discusston of the model's 
assumptions and their ramifications Is a dangerous’ tool 
Indeed. Thus, the user must always have some means of 
observing the effects of the assumptions f[n the model and 
for maktng sure that the APS “knows what he means", The 
model-debugging subsystem of the APS provides the necessary 
mechanism. 


Therefore, for reasons of efficlency, 


(1) The output code and, fn many cases, the assumptions 
underlying its generation will be IncomprehensIble to the 
average user. 
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usabllity, and safety, a model-debugging facility Is a 
necessary part of an automatic programming system. Still, 
the general problem of  model-debugging In automatic 
programming fs much too large to be constdered here. In 
the next section, | will explain the particular subdomain of 
automatic programming 1! will attack, and my reasons for 


choostng [t. 


1.3 Detalis, detallis 


1.3.1 Restriction to the WOBG 


The program described In this thesis fs 
speclalized to work on models chosen from the "world of 
business games" (WOBG). By this § mean an environment In 
which the concepts common to bustness games are the stock 
knowledge. There are several reasons for choosing this 
domain of Interest: (1) the models are suffictently 
structured to be formally expresstble, but are not so 
structured that they are susceptible to mathematical 
analysts; (2) the Interaction of submodels Is the most 
Interesting and complex aspect of the model; (3) this fs one 
of the few domains which tIs_ both renacnablecst zed and 
"real-world" (tn the sense that there Is a great deal of 


Interest In It Independent of this research); (4) It ts a 
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natural subdomatn of the "world of business" (WOB) of 
Protosystem | |9]. 

Models In various domains differ greatly 
In the amount of “structure" present tn the description of 
the model, By “structure” | mean clearly defined rules of 
construction and constralints on elements. The methods’ used 
In thts research require well-defined models. However, If 
the model ts "too well-defined", debuggtIng becomes 
untnteresting, or Is more easily accomplished by 
mathematical tools. The WOBG seems to have just the right 
level of structure, Stnce the Idea of modelling business 
systems Is well established, there exist a varlety of 
formalisms for expressing business models. These modelling 
formalisms are even more clearly defined for busIness games. 
The very Idea of a game [ts to have a precise set of elements 
and rules for manipulating them. Nonetheless, understanding 
and debugging models of business games [Is by no means 
trivial. There Is good evidence that users of even the 
simplest of business games have very poor and "buggy" models 
of what [ts gotng on 131,161,118]. The main reason for this 
ts the complexity of the Interaction between submodels In 
business games. 

j am particularly Interested In 


debugging models tn which Interaction of subparts [is a major 
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factor In model complexity. Most model-worlds which have 
been Investigated In artificial Intelligence research (e.g., 
the "blocks world" |21]) have few complex iInterdependencies. 
Existing fnteractlon problems tend to be downplayed tn order 
to emphas!ize other aspects of the models. (For example, 
see Winograd's "“solutton" to the “findspace problem" in 
12113 cf. 1171.) 1 wish to explore the other end of the 
Interdependency scale; f.e., highly interactive models. (1) 
The kind of models which the program described [In this 
research Is destgned to debug are those In which the user 
has a good understanding of the varlous parts of the model, 
but does not understand how these parts (which I will call 
“submodels") Interact wlth each other. (2) 

In fact, al] of the bugs which the 
program fs destgned to find artse from fnteractton of 


submodels (see sectfon 3.3). Business games have very 


(1) Real world situations presumably fall somewhere’ [n 
between these two extremes. However, | will devote a 
considerable amount of space (all of section 3) to an 
examination of how Interactton of submodels Its the major 
complexity factor In real world situattons (In particular, 
in large bustness organtzations), and how these real world 
Interdependency problems form the "semantic roots" of 
siImllar problems tn the toy-world used In thts research. 1 
am hoptIng to motivate an Interest In the "tnteraction bugs" 
which wlll preoccupy the rematnder of the thesis. 


(2) | belleve that this fs a large and [Important class of 
models, including models of "systems" with well-understood 
elements (see 131). 
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precisely defined elements (see the example game In Appendix 
A). However, these elements Interact with each other to 
the extent that understanding how the "whole system" (f.e., 
all of the Interacting parts) works is a major challenge to 
the players. Thus, stnce poorly understood tnteraction of 
submodels is the major source of bugs In this domain, the 
WOBG forms an excellent testing ground for my program. 

Bustness games also have the  t[mportant 
property of belng interesting in thelr own right. Playing 
and understanding business games Is considered to be an 
Important activity at many schools of management throughout 
the world. There fs therefore little danger of being 
accused of desIigning a program which works only in an ad hoc 
problem domain. Furthermore, since people are used to 
trying to model bustness games for themselves, they can 
apprectate the efforts of a program which atds In the 
debugging of such models. This "real world" flavor of 
bustness games Is one of thetr most important properties for 
this research. 

Finally, the WOBG {is a natural subdomain 
of the WOB of Protosystem 1. This ts useful, first of all, 
because [it allows a certatn iInherftance of philosophy and 
technique from the larger project. More Importantly, 


though, It enables the model-deburger presented here to. be 
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seen In the context of a large automatic programming system. 
SInce the ralson d'etre of my program Is use In an APS, this 
connection with Protosystem |! is an Important aspect of the 
research. 

Therefore, the basic philosophy of 
model-debuggIng presented here will be applted to models 
chosen from the world of business games. In order to show 
that my basic Ideas about debugging are tndeed "working 
Ideas", | have written a program which uses these concepts 


to debug actual models of business games. 


1.3.2 The role of the program in the thesis 


The program presented in this_ thesis 
serves several purposes: Illustration of Important methods, 
demonstration of the workability of the techniques, and 
discussion of design tissues for model-debugging programs. 
Certainly, the major use of the program In the thesis Is to 
provide examples for the debugging theory developed in the 
research. All the major debugging fdeas are Illustrated by 
a scenarlo from the working program. As for the second use 
of the program, a little care Is necessary In explaining the 
"proof" value of the program tn the thesis. It ts often 


contended that working programs prove the utility of the 
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theorfes that they represent. This Is true, so long as the 
reader Is careful not to use some sort of false Induction 
princiIple to tInfer too much from what the program actually 
does. As Its almost always the case, the program In this 
thesis can actually do only a subset of what Is talked 
about. 1 wlll always make It clear what the program can 
and cannot do, how the program can be extended to do more, 
etc. The reader should draw any general 
concluslions--carefully--from this information. 

Using this "“program-as-!]lustrator"™ 
philosophy of presentation, ! will now launch into a 
detailed example of program operation on a simple model. 
This wlll hopefully give the reader a good basic tdea of 
what the rest of the thesis has to say. The issues raised 
In the example and the example itself will be discussed at 
length [tn the rest of the thesis, each aspect of the problem 


appearing In {ts logical section (see table of contents). 
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2 Just to give you an Idea... 


The f{mportant thing to keep’ In mind 
about this program Is that It finds the causes of bugs in 
much the same way that people (or Sussman's HACKER |18]) do: 
by trying to solve problems--and faftling. In this section | 
will present the complete works of my program In connection 
with a very simple example, A lot of nieve notation is 
presented here; please don't get bogged down In It. ! 
present {it here only to avold vagueness in showing what the 
program actually works with. More complete explanations of 
all the notation (and Indeed, the entire example) appear [n 
the approprlate sections later on. This discusston focuses 
on what the program means by a "bug" and on some of the 
procedures used to go from the manifestation to the cause of 
a bug. Neither the procedures nor the descriptive 
mechanisms used by the program are discussed In detall here. 
Philosophical [Issues about representation of knowledge In 
the program and goal-programming are eschewed completely. 
This ts a quick "Introduction by doling" to the methodology 
of the program. 

Suppose the user presents the program 


with the following (tiny) model: 
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Constder the following model 
of sales. A sale Js a_ probabllistic occurence 
which depends only on the amount of advertising 
done, Advertising costs $3000 per page and Is 


good for one quarter. | buy three pages of 
advertising per quarter, If the money to do so Is 
avallable, Sales take place durtng sales calls. 


There fs one call per salesman per quarter. A 
customer never buys more than one unfit. If a unft 
Is sold, the company” records $5000 fn accounts 
recelvable (A-R), which Is not collectable’ for 
another two quarters. At any time, a salesman has 
a 5% chance of quitting. If a salesman quits, a 
new man ts_ hired. After three months of 
training, thfs man becomes a_e salesman and may 
start makIng calls. Both salesmen and trainees 
are pald $1000 per quarter. Tratnees also have a 
5% chance of quitting at any time. 


The user would [Input thls model [Into the program with the 
model specification language presented In section 4.1. In 
these MSL terms, the model looks like: 


(*ACTIVITY HIRING 
(*PREREQUISITES (#PRESENT (1000 CASH))) 
(*SCHEDULE ON QUIT) 
(*PRIORITY 2) 
(*#OUTPUT (SOME TRAINEE) ) 
; (*TAKES 0) 


C*#ACTIVITY ADVERTISING 
(*PREREQUISITES (*PRESENT (3000 CASH))) 
C*SCHEDULE 3) 
(*TAKES 1) 
(*PRIORITY 3) 
) (*OUTPUT (1 PAGE-OF-ADVERTISING)) 


C*ACTIVITY TRAINING 
(*PREREQUISITES 
(AND 
(*PRESENT (1000 CASH) ) 
(*PRESENT (SOME TRAINEE) ) 
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) 

(*TAKES 3) 

(*#OUTPUT (SOME SALESMAN) ) 
) 


C#ACTIVETY SALES-CALL 
(*PREREQUISITES 
CAND 
(#PRESENT (1000 CASH)) 
(*PRESENT (1 UNIT) ) 
; (*PRESENT (SOME SALESMAN) ) 


) 
: (*TAKES 1) 


C(*#ACTIVITY COLLECTION 
(*PREREQUISITES (*PRESENT (5000 A-R))) 
(#TAKES 2) 

; (*OUTPUT (5000 CASH)) 


(*EVENT SALE 
(*CONDITIONS SALES-PROBABILITY) 
C#ACTIVITEES (SALES-CALL) 
C*#OUTPUT (5000 A-R)) 
) . 


) 


(*EVENT QUITTING 
(*CONDITIONS QUITTING-PROBABILITY) 
C*ACTIVITIES (SALES-CALL) 
(*CANCEL) 
(*REMOVE (THAT SALESMAN) ) 


) 
C#ACTIVITIES (TRAINING) 

(*CANCEL) 

(*REMOVE (THAT TRAINEE) ) 


) 
(*FUNCTION SALES-PROBABILITY 


(*#ARGUMENTS (PAGE-OF-ADVERTISING)) 
(#RETURN ad-functlon)). 


C(t will not show the exact nature of 
“ad-function", as It Is a *TABLE construct (see 4.1)-- 
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just a bunch of numbers that we shouldn't worry about 
here (see Appendix B).) 


Now suppose the user gives. the program 
the following: 
(*SIMULATE 4& 1 

((30000 CASH) 

(50 UNIT) 

(DON SALESMAN) 

(MARK SALESMAN) 

(STEVE SALESMAN) 

(BILL SALESMAN) 

(.05 QUITTING-PROBABILITY)) ) 
or, In words, simulate the model for & quarters, showing a 
time-sllce every quarter, and with the given [nfitltal values. 
Before considering the acttons. of the program, {[t_  fs 
worthwhile to note a few things. 

First, observe that the the user has 

given the model (50 UNIT) as an Initial resource. This Is a 
typical example of a model-testing technique: adding slack 
to decouple submodels. Presumably, UNIT Is something 
created by another submodel which the user does not wish to 
consider at this time. The user effectively removes this 
“other submodel" by making sure that the submodel fs never 
limited by the amount of UNIT avallable. (The PRODUCTION 
submodel which creates UNIT's Is shown In Append!x B.)) 


Second, note that we are making an 


implicit assumption about what the user will do with the 
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simulation after It Is presented by the program. We are 
assuming that he will be elther satistied ov dissatisfled 
with the result (1) . If he is dissatisfied, he will express 
his expectation to the system [In the form of a goal. This 
Initlates the debugging process. At this time, let us 
rejoin our example, [In progress. 

The first actlton of the program Is to 
simulate the model as the user requests. t{f the user's 
expectation Is fulfftlled, no further action will be taken 
unt!? the user's next request for stmulation,. if his 
expectation Is not met, the program will help him find the 
bug In the model. | 

The requested simulation 1s shown below. 
The representation used here (and throughout the thesis) 
should be seen as a graphical description of the complex of 
list structure which the program uses to describe simulation 
histories. Every part of the dlagram has an analog in the 
Conniver |20] representation of the program (see section 


4.2), 


(1) We are also assuming that the user Is a good judge of 
the overall performance of the system he Is trying to model. 
This ts of course not Inconsistent with our basic premise 
that the user does not fully understand the workings of the 
system (and therefore has bugs In his model). Rather, we 
are saying that the user knows pretty well what the mode! 
tee do, but Is having trouble making the model do what It 
should. 
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SIMULATION-HISTORY 


*TIME-SLICE O* 


" SALESMEN: DON, STEVE,MARK, BILL 
CASH: 30000 
UNITS: 50 


*TIME-SLICE 1* 


RESOURCES: : 
SALESMEN: DON, STEVE, MARK, BILL 
CASH: 17000 
UNITS: 48 
A-R: 10000 


SCHEDULED *ACTIVITY's: 
. SALES-CALL (DON) 
SALES-CALL (STEVE) 
SALES-CALL (MARK) 
SALES-CALL (BILL) 
ADVERTISING 
ADVERTISING 
ADVERTISING 
COLLECTION (TIME-LEFT = 2) 
COLLECTION (TIME-LEFT = 2) 


SALE (BILL) 
SALE (DON) 


*TIME-SLICE 2* 


"SALESMEN: DON,MARK,BILL 


CASH: 5000 
UNITS: 47 
A-R: 15000 


TRAINEE: G0001 


* Yes 


SALES-CALL (DON) 


SALES-CALL (MARK) 
SALES-CALL CBILL) 
ADVERTIS ENG 

ADVERTISING 

ADVERTISING 

COLLECTION (TIME-LEFT = 3} 
COLLECTION (TIME-LEFT = 2) 
COLLECTION (TEME-LEFT = 2) 
HERENG 

TRAINING (TIME-LEFT = 3) 


SALE €MARK) 
QUITTING (STEVE) 


*TEME-SLICE 3 


RRESOURCES: 
SALESMEN: DON, MARK, BELLE. 
CASH: 2000 
UNETS: 46 
An-R: 16086 


TRAINEE: GO0001 


SCHEDULED *ACTIVITY's: 
SALES-CALL (DON) 
SALES=CALL (MARK) 
SALES-CALE (BILL) 
ADVERT IS ENG 
ADVERTISENG 
ADVERTESING 
COLLECTION (TIME-LEFT = 2} 
COLLECTION (TIME-LEFT = 1) 
TRAINING (TEME-LEFT = 2) 


” SALE (BILL) 


*TIME-SLICE 4e 


" SALESMEN: DON, MARK, BELL 
CASH: 16006 
UNITS: 5 
A-R: Toede 
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TRAINEE: G0001 


SCHEDULED *ACTIVITY's: 
SALES-CALL (DON) 
SALES-CALL (MARK) 
SALES-CALL (BILL) 
ADVERTISING 
COLLECTON (TIME-LEFT = 2) 
COLLECTION (TIME-LEFT = 1) 
TRAINING (TIME-LEFT = 1) 


SALE (MARK) 


The simulation has resulted fn 5 SALE's. 
Suppose that the user expected 6. “There Is a bug In the 
model--but where? Note that the model runs out of CASH In 
the last quarter (and therefore cannot schedule all three 
ADVERTISING *ACTIVITY's). However, the bug fs not "NOT 
ENOUGH CASH", Rather, this effect Is symptomatic of the 
bug. Most of the effort of the program ts to point out 
bugs, not thelr symptoms. But this requires problem-solving 
in the context of the simulation history. Back to the 
actual action of the program... 

The user notes that there were only 5 
SALE's rather than the expected 6. In order to try to 
rectify things, the user gives the system 


(#GOAL CINCREASE SALE 1)) 


The program Is now In the debugging bustIness. It must try 
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to solve the problem of Increasing the number of SALE's fn 
the context of the given simulation history. The places at 
which ft encounters dubious constraints In the simulation 
environment are Its possible locations for bugs. 

The program uses the model and the 
simulatton history to perform the requisite problem-solving 
activity for each goal as It Is presented. This may be 
thought of as asking two questions of the model and the 
simulation: 

(1) Why didn't you do this before? 
and, If there Is no good reason, 


(2) - . How could we do this? 


The method of asking and recelving answers to these 
questions Is best explained by continuation of the example. 
The first goal (given by the user) Is 
(#GOAL (INCREASE SALE 1)) 


Since this goal was given by the user, the first question Is 
not asked. However, the second question Is asked. How can 
we Increase the number of SALE's? By examining the model 
and using the logic of INCREASE (explained In section 
4.4.1), we see that one way to tInmcrease SALE's Is be: 


Increase the probability of a SALE occurtng. Thus, the 


system generates a new goal 
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(*GOAL (INCREASE SALES-PROBABILITY)) 


Now the program asks question number one: why wasn't 
SALES-PROBABILITY higher [In the first place? The program 
looks at the simulation history and notes that the 
SALES-PROBABIL!TY was at a low In time-slfce &. Why Is it 
so low? There was not enough ADVERTISING, the program 
determines. This Is a BAD REASON: the model. was 
RESOURCE-LIMITED, Okay, how can we get the necessary 
ADVERTISING? In order to Investigate this question, the 
program generates a new goal 


(*GOAL (SCHEDULE 2 ADVERTISING 4&)) 


which means "try to schedule 2 ADVERTISING *ACTIVITY's In 
Eine=slitce hY, (The fact that we need 2 ADVERTISING 
*ACTIVITY's fs presumably due to the exact nature of 
“ad-function", and will not be discussed here.) Again, the 
program asks why the ADVERTISING *ACTIVITY's were not 
scheduled In the first place. The answer fs that there was 
not enough CASH; sti1l1 RESOURCE-LIMITED, so we pursue this 
Tine with: 


(*#GOAL (INCREASE CASH 6000 &)) 


By agaln asking the questions and forming new goals, the 
program forms the followIng *GOAL line: 


(*#GOAL CINCREASE CASH 6000 4)) 
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(*GOAL (SCHEDULE 2 COLLECTION 4&)) 
(*GOAL (ALLOW 2 SALE 2)) 
(*GOAL (SCHEDULE 3 ADVERTISING 2)) 


("ALLOW rather than "SCHEDULE" because SALE !s an *EVENT.) 
Note that we are back to SCHEDULIng ADVERTISING. Are we In 
some kind of loop? No, we are moving back In time. 
Furthermore, this time, when we ask why we didn't schedule 

three more ADVERTISING *ACTIVITY's In time-stice 2, we find 
that the reason fs that the user told us not to (via his 
*SCHEDULE specification In the ADVERTISING *ACTIVITY (see 
page 17)). Thus, ADVERTISING [s SCHEDULE-LIMITED In 
time-stfice 2. This {fs a GOOD REASON, and the program 
terminates action on this line of thought. Nonetheless,. It 
saves Information about the terminated line. tf no more 
“likely” bug ts found, the program will tell the user that 
his *SCHEDULE specification for ADVERTISING Is Insufficient 
to allow the model to meet his expectations. In. the 
meantime, however, the program explores the model for more 


likely bugs. The program does this by “backing up" (1) some 


(1) This Is not automatic backup In the PLANNER sense, The 
program backs up only [In certain cases, and only under 
program control. More Importantly, the effects of the 
“backed-over" *GOAL's are “undone” only In the context of 

- The terminated lines must be saved 
for later examinatlton by the program. This [Is essential for 
handling the *GROUP constructs discussed later in the 
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and trying a different line of attack. 
In this case, the program checks to see 
if there Is another way to accomplIsh 


(*GOAL (ALLOW 2 SALE 2)) 


Ustng Its usual questlon-asking procedure, the program finds 
the alternate lI Ine 
(*GOAL (ALLOW 2 SALE 2)) 
(*GOAL (INCREASE SALES-CALL 2 2)) 
(*GOAL CINCREASE SALESMAN 2 2)) 
(*G0AL ( SCHEDULE 2 TRAINING -1)) 2??? 


(Note that CASH does not have to be INCREASEd In this line 
because there Is already a sufficient amount to support the 
new INCREASEs. ) The program Immedtately "otes that it Is 
trying to schedule tn negative time, and terminates the 
Tine, 
This fintshes off the entire 
(*GOAL (INCREASE SALES-PROBABILITY)) 


Idea. But there Is still another way for the program to try 
to get that extra SALE [It is looking for: by trying to 
Increase the number of SALES-CALL's. Thus, 

(*GOAL (INCREASE SALE 1)) 


thesis, and for making final debuggtng recommendations (see 
section 4&.4). 
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(#GOAL (INCREASE SALES-CALL 2 4)) 
(*#GOAL (INCREASE SALESMAN 2 4)) 
(*#GOAL (SCHEDULE 2 TRAINING 1)) 
(#GOAL (INCREASE TRAINING 2 1)) 

(#GOAL CINCREASE HIRING 2 1)) 


(The cholce of time-slice & for INCREASIng SALES-CALL was | 
not arbitrary: the program chooses a slice where [It thinks 
It can do the most good.) But the program cannot accomp]1sh 
this last goal. Why not? The user specifically said not to 
hire until someone quits. The program then checks to see 
If HIRING did [In fact occur. Yes--one time-slice later. 
This particular set of circumstances suggests a common 
timing bug in the manager's “flre-fighting" approach to 
problem solving--no action was taken until it was too late 
for [It to do any good (the solution Is to anticipate 
problems; more detalls about managers’ bugs In section 3). 
Since this bug arises from so specific a group of events, 
the program thinks It is a rather probable bug and gets 
ready to suggest it first. [t then checks to see If there 
are any other ways of INCREASIng the number of SALE's. 
Since there are not, {It Is finished looking for bugs, and Is 
now ready to suggest the bugs [t knows. | 

As advertised, the first bug suggested 


to the user Is: 
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--BAD *SCHEDULE FOR HIRING: DEPENDENT ON QUIT; HIRING 
TOO LATE 
The user may agree that this Is the bug (J think it Is), 
or ask the program to try again. The next bug’ suggested 
ts 


--BAD SENSE OF PRIORITIES: HIRING AND ADVERTISING 


Essentlally, the program suggests that It could have 
gotten more ADVERTISING If HIRING did not have higher 
priortty. If the user doesn't buy this, the program 
suggests that he sImply blew the *SCHEDULE specification 
on ADVERTISING: 

--BAD *SCHEDULE FOR ADVERTISING: NOT ENOUGH 


If the user still doesn't like what's happening (and 
siInce the program has suggested all of the bugs it 
found), the program decides to see If the user might have 
mis-specified or completely omitted a relevant part of 
his model (this happens more often than you might think) 
It then uses its access to WOBG knowledge to suggest 


--MISSING *ACTIVITY: FACTORING 


(the user may factor accounts-recelvable to provide 
Instant cash) and 


~-MISSING *ACTIVITY: RESEARCH AND DEVELOPMENT 
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(the user may Increase the probability of a sale by 
Improving his product). 

The program goes. out of the debugging 
business whenever the user takes a suggestion, or, of 
course, when fts. bag of tricks Is exhausted. The user 
can now fix his model or change his. expectations and 
re-stmulate. Eventually, this process of simulatton and 
debugging will converge to a model that the user Is 
confident that he and the APS _ both understand 
sufficiently. 

In this sectton | have tried to show 
a complete ehanbte:.of what this thesis fs about. | witl 
now go. Into an examinatton of the foundations of this 
approach, and the techniques that. allow its 
Imp Lementatton.. | begin with a philosophical discusston 


of bugs Cyech). 
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3 Bugs 


A bug fs something that prevents 
something from behaving the way someone expects it to. 
This section particularizes the notion of "bug" to a 
concept which fs useful for this research. As usual, the 
program only knows about a narrowed-down version of 
"bug", 

We will be [Interested here only in 
“understanding-bugs"=-I.e., bugs that exist only In the 
user's understanding of the system he wishes to model 
(cf. Goldstein's "semantic bugs" [5]). This Immediately 
removes from consideration "parenthesis errors" and other 
"syntactic bugs" (of course, trivial syntax bugs 
sometimes arlse from a basic misunderstanding). Thus, 
there wlll be no Interest whatsoever in finding bugs due 
to MSL errors. In fact, no attention Is given to bugs of 
any kind that arise from careless expression of the 
user's knowledge In the modelling formallsm. 

| The kinds of bugs with which the 
program Is concerned are those that seem to be "Inherent" 
In the way people understand (or misunderstand) systems. 
The rest of this sectfion will be devoted to an 


examination of bugs that occur [In the modelling process 
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and the features of the problem domain that cause them to 


occur. 
3.1 Bugs in models 


3.1.1 What did 1 do wrong? 


What happens when people try to model 
systems? They usually do some mumb 1] Ing and 
head-scratchIng and come out with some sort of expression 
of thelr tdeas. In this research, the "expression" Is 
required to be rather formal, but this doesn't matter 
much. Next, the modeller somehow tests his model to see 
how It performs under various conditions (just as my 
system uses simulation, see section 4.2). Most of the 
time, the mode! does not perform as the modeller expects. 
It to--"something goes wrong". 

Actually, “something went wrong" at 
define-time: there Is something tn the definition of the 
mode] which Is causing the unexpected behavior. I have 
already mentfoned the hypothesis that the user has a good 
understanding of each submodel. (1) Thus, the part of 


the model definition which fs In error must be a 


(1) The notton of "submodel" will become much more precise 
when | discuss MSL fn section 4.1. 
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specification of submodel Interaction. The 
manifestation of such a bug varies widely with the 
particular bug Involved, and tends to be a detalled 
matter (f.e., highly dependent on the actual 
representation formallsm). Therefore, 1! will postpone 
(th discussion of this problem until after I have 
described the formalism (4.4.2), and go on to an 
examination of the "semantic roots" of these "fnteraction 


bugs", 


3.1.2 Interaction bugs 


In order to understand the Idea of 
Interaction between submodels, it Is helpful to view the 
model as a process which defines the action of the 
modelled system. Thus, the models we will examine here 
all "do something". The model can be seen as a_ system 
which converts some sort of input resources Into some 
predefined outputs. (This Is, In fact, a very popular 
view of management’ systems.) For the model to "do" 
anything, its submodels must Interact with each other. 
That Is, the [Inputs to the entIre model are actually 
Inputs to certain submodels which convert them Into 


Intermediate quantitles which are tn turn Inputs to other 
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submodels--and so on until the desfred outputs are 
obtained. 

Via this Interaction, varlous 
dependencies between submodels arlse. The most common 
Is that one submodel must walt for the completion of 
another before It can begin action. (See section 4&.4& for 
a detalled account of different kinds of Interaction 
between MSL submodels.) Also, submodels often share 
basic resources, giving rise to conflicts between 
submodels. 

These dependencies and conflicts 
between submodels provide the environment for the 
following basic "Interaction bugs": 


(1) Unexpected conflict arising from competition for 
shared resources 


(2) Weak performance due to poor perception of 
ttme-phased occurences 


(3) Spectal complexity problems arising. from the 
concentration of (1) and (2) In "tight systems" bound 
by higher-order constraints 
Although If belleve that these bugs have considerable 
generality, 1! will not discuss them In the abstract. 


Instead, |! wlll move Immediately tnto the domain of 


management systems to provide a framework for discusston. 
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3.2 Jnteraction In management systems 


The bugs catalogued In the above 
subsection arise from poor understanding of complexity. 
This "complexity" Is directly inherited by the models from 
the modelled domain. As an introduction to the’ Interaction 
complexity of organizations In the world of business (which 
form the basis for busIness games, the "modelled domain" of 
this thesis), I will quote In full an fllustrative passage 
from Galbraith 14]: 


There fs considerable varfation in the 
amount of f[nterdependence [fn organizations. The 
kinds of varlattion can be Tllustrated by 
considering a large research and development 
laboratory employing some 500 scientists who are 
pursuing the state-of-the-art. Thus we have a 
large number of elements and high task 
uncertainty. However, there fs little need for 
communication. All the projects are small and not 
directly connected to other projects. Therefore a 
schedule delay or a destgn change does not 
directly affect other design groups. The only 
source of Interdependence fs that the design 
groups share the same pool of resources--men, 
facilities, ideas, and money. But once the 
Intttal resource allocations are made, the only 
necessary communication between desftgn groups Is 
to pass on new Ideas (Allen, 1969). This type of 
interdependence’ has been termed as pooled 
(Thompson, 1966, Pp. 54-5). 

If the nature of the projects 
Is changed from 250 small itndependent ones to two- 
large ones, a different pattern of Interdependence 
arises. The large projects will require 
sequential designs. That Is, a device is first 
designed to determine how much power [t will 
require. After It Is complete, then the design of 
the power source can take place. Under these 
conditions, a problem encountered tn the design of 
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the device will directly affect the group working 
on the power souce. The greater the number of 
problems, the greater the amount of comuntcat!Ion 
that must take place to jointly resolve problems. 

The second example describes a 
situation which ts more complex and requires 
greater amounts of information processing. The 
second example has all the problems that were 
described [In the first example. There must be 
budget and factlities allocations made under 
conditions of uncertainty. There must be a flow 
of new fdeas among the technical spectalties. 
But, In additton, the second example requires 
information processing and decision making to 
regulate the schedule of sequential activities. 
This ts because there !s greater Interdependence 
In the second example. 

The Interdependence or 
Interrelatedness of the design groups can be 
Increased above what Is descrtbed In the second 
example by the degree to whitch “desten 
optimization" its pursued. Optitmizatton means that 
a highly efficient device Is desired and any 
change in the des!Ign of one of the components 
requires redesign of some others. 


This can be Tllustrated by an 
automoblle engine and body. The handling 
qualities of a car depend on the welght of 
the engine. The engine compartment can hold 
only a certain sfze of engine with its 
accessories. The drive shaft and 
differential can handle only a limited 
amount of torque. Changes In the welght, 
size, or output of the engine may 
necessitate changes [n the body of the 
automobile. These [nterrelations and many 
others must be taken’ tInto account [n the 
design of an automobI le. 

Actually, in the case of a 
passenger automobile there Is a good deal of 
flexibility with regard to  body-engine 
match. The engine compartment fs usually 
large, the parts of the suspension are 
easily changed, and the drive shaft probably 
has plenty of excess torque-carrying 
capabilty. Engines of a varfety of shapes 
and sizes are frequently placed In the same 
body. But this need not be the case. In 
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high-performance automobiles, the sfze of 
the engine compartment [Is frequently sharply 
constralned by aerodynamics considerations. 
There may be efforts to lighten the whole 
automobile by making parts of the drive 
system and body as lIght as possible; given 
the required strengths. In such a 
situation, the flexibilftty tn the stize, 
shape and performance of the engine placed 
In the body Is sharply reduced or 
elfminated. (Glennan, 1967) 


Thus the high performance auto [s a highly 
Interrelated system while the passenger car is a 
flexible, loosely coupled system. The same is 
true of organizatfonal subunits which must design 
these systems. Any change [In the engine deslIgn 
for the high performance car must be communicated 
to the group designing the body so that an optimal 
fit fis still achieved after the change, This ts 
less true for a passenger car. Therefore, the 
organization desfgning the high performance car 
must be capable of handling the [nformation flows 
described in examples one and two for. budgets, 
ideas, and schedules and also those for all 
design-redestgn decisfons deriving from the 
interrelated design. The amount of information 
that must be processed increases as the amount of 
Interdependence Increases. 


Each of Galbraith's examples illustrates 


a kind of interdependency between subunits of an 


organization. The first kind, pooled interdependency , 
gives rise to interaction bug (1) of the previous 


subsection. That Is, when resource sharing is present, there 
is llable to be unexpected conflict between subunits trying 
to use the same resources (These are the PRIORITY bugs of 
the example in sectfon 2). Galbraith next cites an example 


of sequential Iinterdependency, I.e., interaction over time 
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as well as_ resources. Again, this second kind of 
interdependency provides an environment for the second kind 
of Interaction bug: when subunits Interact over time, the 
modeller is ltable to mis-estIimate tIime-effects, thus 
causIng degraded performance (these are the SCHEDULE bugs of 
the example In sectlon 2), Finally, Galbraflth mentions 
higher-order constraint Interdependency. (1) Essentially, 
this means that a higher-order objective, shared by a group 
of subunits, has forced a need for greater [nterdependency 
among the subunits of the group. What has happened [s_ that 
in the new "ttghter™ system, the pooled and sequential 
Interdependency has been spread to more (sometimes all) 
members of the interactive group. This kind of 
Interdependency has a_ direct Interpretation In the WOBG 
which will be discussed in the next subsection. The third 
kind of Interaction bug from sectton 3.1.2 of course arlses 
from the higher-order constrafnt environment. (There are no 
examples of this kind of bug In the example of section 2; 


higher-order constrafnts were delftberately kept out for the 


(1) 

| think that the tntroductton of the "destgn 
optimization" term here Is very unfortunate, The point fs 
that the subunits have become more Interactive due to the 
presence of a higher-order constraint. In this case, the 
constraint happens to be that the unfts must [Interact In 
order to achleve an optimal design. However, in the next 
subsection | wlll discuss other higher-order constraints 
which cause the same increase in Interaction. 
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sake of simplicity. There wlll be examples of this kind of 
bug later in the thestfs.) 

These three types of Interdependency 
form the semantic roots of the bugs considered by my 
program, In the following subsection we will examine the 
way these real world organlizatlonal dependencifes are 


modelled In the world of bustnes games. 


3.3 Bugs In WOBG models 


Business games provide a taboratory for 
teaching managerial deciston-making. Since most Important 
management dectsions Involve resolving conflicts (or 
possible conflicts, in the case of planning) aritstng from 
subunit Interdependency, the three kinds of 
Interdependencles discussed In the previous section are 
emphasized In many business games. And, of course, with the 
three Interdependencles come the three Interaction bugs. 

Pooled Interdependency arlises from a 
natural sharing of resources by different parts of the 
game-player's "“busIness". The business game contains a 
- very well-defined set of "resources" (cash, salesmen, 
production-lines, etc.) which the player must manfpulate 


accord ng to certain specified rules of play. (1) The basic 
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Idea Is to accumulate certain resources which are deslgnated 
as “assets". There are a variety of strategles for 
accumulating assets (e.g., use research, do some 
advertising, learn about market trends, etc.). The 
Important potnt for us Is that the Implementation of any 
strategy requires manipulation of vartous subunits of the 
player's “bustness", These subunits share the pooled 
resource of cash. Since cash Is In IJtmited supply, an 
Interdependency Is set up, and conflicts artse. Poor 
understanding of this pooled interdependency gives rise to 
sectfon 3.1.2's bug type (1): “unexpected conflict arising 
from competition for shared resources." 

A much more Interesting aspect of the 
particular game I have selected Is the sequential 
interdependency among subunits. First of all, note that 
some of the activities of the subuntes are "long-term" 
(research and development, training sales personnel, 
constructing additfonal production capacity, etc.), while 
others are "short-term" (advertising, factoring accounts 
recelvable, hiring, etc.). Second, there Is considerable 


linkage between the requirements of some activities and the 


(1) This discussion fs based on the actual business game 
presented [n Appendix A--it might be a good Idea to glance 
over the description of the game to give yourself the flavor 
of what's golng on. 
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"outputs" of others (product ton provides units to sell, 
hiring provides employees to train, etc.). Finally, the 
game contains a rather rich "posstblllty space" for any 
given strategy If the time-scale Is long enough. That Is, 
there are a vartety of non-Independent ways of golng about 
achieving a given task over time. All of this (plus_ the 
addition of probabilistic occurences over time) adds up to a 
complex pattern of sequential dependectfes, which fn turn 
gives rise to“ bug (2), “weak performance due to _ poor 
perception of time-phased occurences". 

It Es characterftstic of the game used 
here (and ef most other business games) that the pooled and 
sequential interdependencles are frequently made more 
Intense by "higher-order constralnts". These constraints 
arlse fromthe activity structure of the game. The key 
factor Is that varlous activities and functions of the 
organization depend on the outputs of more than one prior 
activity (note that this was not the case In the example of 
sectlon 2, and thus thls problem was avolded). I can 
present a detalled account of these mutual Interdependency 
relationships only after I! discuss the way the game Is 
modelled fn MSL ( ! wlll do this [In 4.4). For now, [It will 
suffice to say that two kinds of higher-order constraints 


are distinguished: the kind In which several activities (or, 
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more usually, chains of activities) must combine to provide 
resources for another activity, and the kind In which a 
number of activities can combine fn various unstructured 
ways to achleve a functionally-determined goal. 

This section has been devoted to filling 
In rather general background Information about the kind of 
bugs the program knows about and how these arise naturally 
In real world systems. We now go on to an examination of 
how the program [Incorporates some knowledge about cress 
bugs, and how {it goes about using this knowledge to debug 


models. 


‘Page 47 


4 How the program works 


In this section I will present a program 
which finds the kInd of Interaction bugs discussed above. 
An example of program operation has already been shown In 
section 2. From this example, the following pattern of 
program operation Is evident: the program starts with a 
model represented [n a special formal language; it takes 
this model and produces a simulation of it; If the user 
finds a discrepancy between his expectations of model 
performance and the results of the simulation, he presents 
the program with the goal of eliminating the discrepancy. 
The program then attempts, using both the model as 
originally stated by the user and the results of the model's 
simulation, to achieve that goal; in the course of falling 
to achieve that goal (1) , the program finds features of the 
model which It considers to be unintended causes of the 
fallure-~bugs. tt then suggests these bugs (in order of 
"ltkelfhood") -to the user, leaving him to take the next step 
(and perhaps re-IinIitflate the process). | 


This sectton considers each aspect of 


(1) The program fall to achieve almost all user 
goals! (The almost" is due to probabilistic 
considerations.) Otherwise, there was not a bug and the 


simulatton would have achleved the goal [In the first place. 
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this process in turn. tt begins (4.1) with an examination 
of the model specification language, providing a firm basis 
for understanding what the program does and does not know 
about the user's model. Next (4.2), [It describes the 
simulation of the model and the way the results of the 
simulation are presented to the debugger. Continulng along 
the debugging process, section 4.3 deals with the way user 
goals are formed and the way [n which the system handles 
goals. Section 4&.& can then talk about how the program's 
deductive mechanisms pursue goals and locate bugs-~-the real 
guts of the debugging problem, Finally, there {fs a short 
section (4.5) on the way the program uses real-world 
knowledge In the debugging process. 


Into the heart of darkness... 


4.1 The model specification language 


In order for the program to use the 
simulate-and-InvestIigate method for debugging models, the 
models must be represented [na form that Is executable (by 
the simulator) and a form ‘that Is examinable (by the 
problem-solving routines). The model specification. 
language (MSL) is an attempt to combine these two necessary 


forms tna stngle language (which also purports to be falrly 
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user-orlented!). 

MSL fs a set of simple primitives which 
can be used to describe models--especially business game 
models (1) . An MSL specIficatton consists of an 
(unordered) collection of the three basIc primitives 
*ACTIVITY, *EVENT, and *FUNCTION, The basic primitives are 
further described by modifying constructs. The model 
manipulates user-defined value/term pairs called "resource 
varfables" (e.g. (1000 CASH), (SAM SALESMAN), etc.). An 
example of MSL specifications appear on pages 17-18, and in 
Append!x B. This section contains a brief description of 
the syntax and semantics of these MSL primitives. 

The basic MSL construct Is the 
*ACTIVITY. The concept of "activity" used here is precisely 
similar to the usual business sense of the word: a 
well-defined organizational task which processes’ some 
commodities or iInformatton that Is used by the organization 
(see section 3.1.2; see also the WOB |9{ for Its Information 
on activities). An *ACTIVITY also corresponds to a submodel 


(2) --that thing that the user Is supposed to have a good 


(1) No claim ts made for any "completeness" or "suffictency" 
of this set of primitives. These are simply constructs 
which can be used to express my game models. 


(2) We will see In a few minutes that *EVENT's) and 
*FUNCTION's are also submodels. 
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grasp of (see 3.1.1).The *ACTIVITY specification looks ltke 


(*#ACTIVITY <#ACTIVITY-name> <modifiers>) 
(1) 


As ts usually the case, the modifiers are the most 
interesting part of the specification. 

One modifier which Is almost always 
present Is the *PREREQUISITES specification. This 
construct expresses the necessary Inputs of an *ACTIVITY. 

The *PREREQUISITES specification 


contains an arbItrary number of 
(*PRESENT <resource varlable>) 


forms grouped (implicitly) by OR or (explicitly) by AND. 
The basic Interpretation Is that the named <resource 
variable> must be present (2) for the #ACTIVITY to be 
Initiated, If there is an AND specification, then (as one 
would expect) all of the "AND‘ed" resource variables must be 


*PRESENT. Thus, fn 


(1) 1! wtll use the followfng notation: "<" and ">" are 
metalingulistic brackets which surround metalingulistlic 
statements. Everything else belongs there. 


(2) Clearly, there are the obvious extensions 
"*#MAY-BE-PRESENT", "MUST-BE-PRESENT", etc. 1 have not found 
these concepts necessary to express the models |. have used. 
Therefore, they are not Included In the MSL, even’ though 
thelr Introduction would be straltghtforward. 
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(*#ACTIVITY SALES-CALL 
(*PREREQUISITES 
CAND 
(*PRESENT (1000 CASH) ) 
(*PRESENT (1 UNIT)) 
(*PRESENT (SOME SALESMAN) ) 
) 


?) 


there must be (1000 CASH), (1 UNIT), and (SOME SALESMAN) for 
SALES-CALL to be Inittated. 

Some further comment is necessary on the 
quantification mechanism of *PRESENT. The "SOME" In (SOME 
SALESMAN) represents any name of a SALESMAN Tn the 


model.That is, 
(*PRESENT (SOME SALESMAN) ) 
will be satisfied with 
(MARK SALESMAN) or 
(DON SALESMAN ) or 
(STEVE SALESMAN) 


Numerical quantificatitons carry an Implicit “at least" 


modifier. That fs, 


(*PRESENT (1000 CASH)) 
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will be satisfied with 
(10000 CASH) or 
(1000 CASH) 
but not (999 CASH) 


The “at least" modifier may be explicitly stated, or may be 


changed to AT-MOST, as In 
(*PRESENT (1000 CASH) AT-LEAST) 


(*PRESENT (5 ERRORS) AT-MOST) 
The “outputs” of an ACTIVITY are 


expressed by the *OUTPUT and *REMOVE constructs: 
(*#QUTPUT <resource variable>) 
-(*REMOVE <resource varlable>) 


which add or delete the named resource vartlable from the 
model's resources, — 
An *ACTIVITY construct may be further 


described by: 
(*TAKES <number>) 


to Indicate that If the *ACTIVITY Is Inittated In time-slice 


hn, Its outputs do not become avatlablte untI] time-slice 
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n+<number> . The purpose of this Is, of course, to allow 
the modelling of *ACTIVITY's which take an appreclable 
amount of time to be completed. Another important 


modifier, 
(*PRIORITY <number>) 


allows the user to Indicate preference [n allocation of 
resources to *ACTIVITY's, Thus, If several *ACTIVITY's are 
vying for the same resource, the one with’ the lowest 
*PRICRITY <number> has flrst crack at ft (1) . 

*SCHEDULE specifications allow the user 
to give explicit scheduling Information to the simulator’ in 
order to lfmit the use of an *ACTIVITY. The specifications 


that have been found useful so far are 
(*SCHEDULE <number>) 


to limit the number of times an *ACTIVITY can be scheduled 


In any time-slice, 
(*SCHEDULE (ON <#EVENT=-name>) ) 


to allow the scheduling of an *ACTIVITY only in the same 


(1) Agatn, obviously, this sftmple mechanism could be greatly 
expanded. More complex models would require time-varying 
and other computed *PRIORITY specifications. These have not 
been [Included tn MSL. 
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time-slice as the occurence of the named *EVENT, and 
(*SCHEDULE CEVERY <number>)) 


to limit the scheduling of the ACTIVITY to time-slice 
<number>,2x<number>,3x<number>,etc, 

The above modifflers, along with the 
user's abllIty to create resource varlables and provide 
arbitrary *ACTIVITY structures, allow enough flexibility to 
express all of the *ACTIVITY's necessary to model the game 
in Appendix A (see the model In Appendix B). There are, 
however, other kinds of submodels to be considered. 

Another basic construct (Tl.e., 
submodel-specifler) available to the modeller Is the *EVENT. 
This ts used to express parts of the model which are 
“outside of the system"--beyond the organization's direct 
control. These outside influences are often modelled as 
probabilistic occurences, so that *EVENT's are usually 
associated with the probabilistic parts of the model. 


*EVENT is very stmilar to *ACTIVITY tn basic syntax: 
(#EVENT <#EVENT-name> <mod!fiers>) 


but the modiffers are somewhat different. 
Instead of the *PREREQUISITES 


specification, a *CONDITIONS lIst Is stated: 
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(*CONDITIONS <boolean expresston>) 


That Is, the sItmulator expects the body of a *CONDITIONS 
lIst to evaluate to "true" or "false". Usually, the body 
contains some combination (ba Fhiapé related by AND or OR) of 
*FUNCTION names (1) (see below). The intent is that the 
*EVENT may not. be Initlated unless the <boolean expresslon> 
evaluates to "true", 

Usually *EVENT's affect particular 
*ACTIVITY's.The suscteptible *ACTIVITY's and the actions to 
be taken by the *EVENT are expressed within the *EVENT by 
the *ACTIVITIES modifier: 


 (#ACTIVITIES (<ltist of *#ACTIVITY-names>) <acttons>) © 


If an *EVENT contalns an *ACTIVITIES construct, It can be 
inftlated only In a time-slice In which at least one of the 
named *ACTIVITY's Is scheduled. 

| One rather unusual <action> which can be 


taken by an *EVENT Is 


(1) These *FUNCTION's usually express a probability with 
which the *EVENT occurs in ae given time-stice. The 
sImulator sets up a probabilistic event (no confusion, 
please!) on the related sample space to express” the 
*FUNCTION. It then calls a random number generator. If the 
value returned by the RNG falls within the defined event,the 
simulator assigns "true" to the value of that *FUNCTION. 
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(*CANCEL) 


This means that the Interrupted *ACTIVITY has been 
permanently disrupted, and ts to be unscheduled, (Of 
course, It can be rescheduled later.) In all other 
respects, *EVENT's are treated just like *#ACTIVITY's.. 

The final basic construct In MSL Is 
*FUNCTION, It expresses a functional relationship between 
variables In the model, and, In general, accounts for 
Information flow within the model. It is thus slightly 
different In spirit from the pasouree handling *ACTIVITY's 
and *EVENT's. Nonetheless, It shares submodel ‘status (1) , 


and is stmilar In syntax to the other two basic constructs: 
(*FUNCTION <#FUNCTION-name> <modiflers>) 


*FUNCTION's are not "Scheduled"; rather, they are Invoked by 
being mentioned In other constructs (just as In programming 
language function calls). Thus, whenever SALES-PROBABILITY 
(see section 2) appears In the model (except In the 


*FUNCTION definition, of course), the *FUNCTION 


(1) It Is important to recognize that informatton-hand1 Ing 
activities are submodels at the same level as other 
organizational activities. Forrester stresses this point 
In [3], and seems to use the homogenelty of basic submodels 
successfully. Of course, the uniform submodel constructs 
also lead to a gain In modelling effictency and a lessentng 
of the cognitive load of the MSL user. 
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. SALES-PROBABILITY will be Invoked. 


The analogous construct to 


*PREREQUISITES and *CONDITIONS In *FUNCTION Is 
(*ARGUMENTS <argument1> <argument2> ...) 


which behaves like the usual argument<-lfst [fn programming 
language functlons. Missing arguments cause an “error" 
which stops the simulation (1) . 


The analogy to *OQUTPUT Is 
(*RETURN <expression>) 


where <expresston> can be a combination of *FUNCTION names - 


and the special functlon-representing constructs 


(*TABLE (<#ARGUMENT=name> <*#RESULT-name>) 


<argument/result palirs>) 
(*SUM-UP (<variable range>) <lfinear factors>) 


This fs about all there Is to the MSL. 
The semantics of *ACTIVITY's and *EVENT's are developed a 
bit further in the next section. *FUNCTION's are dealt with 
in &.4.2.1.. However, no really detailed descriptions are 


presented anywhere. There is little polnt In It. The only 


(1) This fs, of course, the kind of bug we're not Interested 
In here. 
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purpose of presenting MSL Is to allow the reader to 
understand the examples and judge what the program does and 
does not know about a particular model. 

Almost all of what the program knows 
about any given model is In the MSL specification. Cit 
knows a few other things discussed In 4.5.) MSL can be 
simple because the models considered are quite simple. As 
the models become more complex we expect (by conservation of 
complexity) that MSL will become more complex. The hope Is 
that MSL contains something general enough to handle some 
kinds of additional model complexity without additional 
language complexity. This “something" Is the basic 
philosophy of submodel structuring which Is reflected in the 
MSL. Thus, I have tried to emphasize this basic structure 
rather the detalls. In the next section we follow. the 
course of the program's debugging process wad examine the 


stmulatton of MSL models. 


4.2 Simulation as a way of doing things 


Simulation fs a technique for observing 
the behavior of models. In the absence of analytical and 
other "high-level" tools (like educated guesses), simulation 


Is the only way to find out wha a model “does" In any given 


eee nce nee ene een = ne are ACER eA AAG AS eA SECOND SE cS 2 
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sttuatlton. In the model-debugging system presented In this 
thesIs, the stmulator sets up the basic feedback mechanism 
between user and APS, 

At the very least, any APS should 
provide a facility for checking out model behavior with 
stmulatton. That fs, the user formulates his model, tests 
It via simulation, changes it if he doesn't like what he 
sees, and resimulates, For reasons discussed in the 
Introductory section, It Is necessary to go a step further. 
The program described here attempts to aid the user in 
discovering why the model does not perform as he expects it 
to. 

Therefore, this section wlll concentrate 
on simulation as a way of [Initiating the debugging process. 
This emphasts Ignores very important [fssues of presenting 
stmulation results to the user, In fact, It completely 
downplays the Importance of the simulator Itself, 
concentrating only on the [nteractton of the simulator and 
the deductive mechanisms of the debugging program. Thus, 
In thts section I wlll proceed to flnesse the simulator and 
move on to the more relevant problems of representing the 
knowledge gained by the simulatfon In such a way that [it can 


be used by the debugger. 
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4.2.1 Ihe simulator finessed 


In this section t willl very briefly 
describe the simulation scheme used In the program. The 
whole simulation philosophy presented here Is kind of 
strange as viewed from the standpoint of normal" simulation 
programs, This fs due to the presence of two major design 
criteria not usually found [fn the area of simulation 


programming: 


(1) Adherence to the “user only knows local submodel! 
Information" canon ennunclated earlier (sections 1.3.1 


(2) The goal of representing knowledge found by the 
simulation In such a way that It can be used by the 


debugger 


The first criterion gives rise to those funny MSL constructs 
which mysterlously appeared in_ the previous discussion. 
It also motivates the style of simulation described in the 
rest of this section. The second criterion determines the 
actual Implementation of the algorithm, and is dealt with In 
the following subsection. | 


In MSL, the Information pertaining to a 
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particular submodel is found only In that submodel. The 
kind of "Information" varies from submodel] to submodel (as 
described In 4.1), but basically, the following 


specifications are necessary: 


--resources needed by the submodel 


--resources produced by the submodel, and the length of 


time necessary to produce them 


--expliclt policy for the conditions under which the 


submodel should be actI vated 


The basic operation of the simulator is 
then stralghtforward.Each submodel ts activated when its 
(user-specified) explicit pre-conditions are Sarietieds 
provided that all of Its necessary resources are avalflable. 
If the user does not specify pre-conditions (vila *SCHEDULE 
and *CONDITIONS--see 4.1), the submodel Is activated 
whenever Its necessary resources are avallable (subject to 
*PRIORITY restrictions, of course). When the time 
(specifled by *TAKES) for submodel activity has elapsed, the 
output resources of the submodel (If any) become avallable 
to the whole model. This process of cycling through 


submodels activating "ready" ones, continuing "running™ 
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ones, cleaning up finished ones, and augmenting and 
depleting resources all along continues for the duratton of 
the user-specified run-length. 

Now anyone who has ever glanced at’ the 
guts of a simulator knows that I have just’ finessed 
Inumerable details (as well as a few Important Polnts). The 
algorithm used In the program is actually a bit = more 
sophisticated and a great deal hatrier than the one 
"described" above. For example, | have not. even’ mentioned 
the rather ticklish problem of handling probabilistic 
occurences in this context, nor the design decisions for 
priorlty-scheduling of already~running submodels. t am 
dellberately sluffing the detalls here because the simulator 
Itself is not very fmportant to the thests as a_ whole. It 
Is ts output, the SIMULATION-HISTORY context, that 1! wish 


to emphasize here. 


4.2.2 Simulation history and SIMULATION-HISTORY 


The form of the output of a stmulatton 
Program ts always a key factor In Its usefulness. In the 
debugging system presented here, it fs an essential link 


between the model and the deductive mechanisms. of the 
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debugger. As discussed above, much of the task of the 
stmulator Is to present the knowledge gained by simulating 
the mode! In a form that can be used by the rest of the 
program, This Its of course the old artificial intelligence 
task of representing knowledge In a form that can be used by 
procedural deductive mechanisms. 

The style of representation |! have 
chosen for the simulation knowledge Is the simulation 
history. Now this Is hardly startling--simulation 
histories are frequently used to describe the behavior of 
systems. But here | wish to extend the concept somewhat. 
In my program, the stimulator constructs a simulation history 
(called SIMULATION-HISTORY) which then becomes’ the 
problem-solving environment of the debugger. By this |! 
mean that from the point of view of the deductive mechanisms 
In the debugger, the “world" Is a simulation history; f.e., 
a sequence of facts about the model which are true at 
varlous times determined by the simulation. | The debugger 
lives Inside this simulation history. The things that It 
knows about the "world"--the kinds of knowledge found, the 
way events are related, etc.-- are the facts and rules of 


the simulation history world (1) . tn thinking about the 


(1) Except for, as we shall see later, the facts {ft knows 
about the "real world" of business games. 
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debugger, It Is well to keep [n mind that ft Is a citizen of 
the simulation history world. 

Well then, Tet's go slumming and look 
around the simulation history world ourselves for a few 
rollicking moments. Consider some set of observational 
varlables on a simulation model. Then a simulation history 
can be thought of as a recording of the “values” of these 
variables at varlous I[nstants of stmulat fon-time. The 
Interesting questions are what observational varlables 
should be used and how the record should be organized. We 
will see that these questions are Important with respect to 
the usefulness of the simulator to the debugger. 

For the simulation to progress from one 
time instant to the next, the simulator must have aé_ record 
of the state of the simulation. The simulation. state of 
these simple MSL models consists of four main. pleces of 


informations 


(1) the value of each "resource varltable" (see 4.1) at 


the end of each time-slice (1) 


(2) a record of the *ACTIVITY's which were [Initlated In 


the time-slice 


(1) A time-slice ts one ker-chunk of the simulator. 
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(3) a record of the *EVENT's which occur and_ the 


*ACTIVITY's they affect 


(4) an tIndtcation of the stage of completion of each 
"running" (t.e., previously Infitfated and not yet 


complete) *ACTIVITY and *EVENT 


Therefore, the stmulator needs these four pleces of 
Informatlon at the end of each time-slice [tn order to go. on 


to the next time-slice. 


But what does this have to do with the 
"observational variables" for the simulation history? First, 
remember that the "observer" In this case fs the deductive 
mechanism of the debugger. Now, harking back to all that 
was sald tn secttons 1 = and 2 about debugging by 
problem-solving, we can see that the debugger is usually in 
the position of trying to change the course of the 
simulation In some way (to cause some desired outcome which 
causes another desired outcome, etc... which eventually 
causes the user's desfred outcome). In order to decide 


whether [It can make the change (1) [ft must know something 


(1) Of course, [It must also decide whether the user wants 
the change to be made. This part of the problem Is 
discussed In 4.4.2, 
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about the simulation. Specifically, ft must know the state 
of the simulation and ways to change that state (1) ; The 
ways to change the state are encoded In procedural deductive 
mechanisms to be described later (h.k,1), The state of the 
simulation | Sati be provided by the simulation history. 
Therefore, the observational varlables for the simulation 
history are just the state varfables discussed above (2) . 

Well, sfnce the stimulator needs the 
values of the state varlables at the end of each tIime-slice, 
the program need only keep track of these values In some 
useful fashion. The problem now becomes one of organizing 
the simulation history. In order ot think about such an 
organization, we can look back to section 2 and remember a 
bit more about what the deductive mechanisms do with the 
simulation history. 

The deductive mechanisms usually find 
themselves playing around In thelr little simulation history 


world In two ways: 


(1) examIning a single time-slice to see whether a 


change can be made at that time 


(1) This Is Its “world knowledge" of the simulation history 
world, . 


(2) A schematic representation of these state variables as 
they appear In the simulation history Is found on pp. 21-23. 
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(2) examining a large segment of the simulation to 
choose a I!kely time-slice for scheduling something 
new, to follow the course of an *ACTIVITY or *EVENT, to 
pursue the consequences of a proposed change, or (as we 
shall see later In this section) to handle higher-order 


constraints 


What we need Is a good representation for facile handling of 
time-slices and (usually contiguous) groups of time-slices. 
The representation should also allow ease In the bullding-up 
and mantpulation of the whole history. 

Such a representation fis the Conniver 
context [20]. The stmulation history is implemented as a 
Conniver context with the unlikely ‘moniker of 
SIMULATION-HISTORY. Each time-slice is a layer [20] of the 
context. This Conniver implementation [fmplfies the following 
relation between’ time-slices: the sftmulator "grows" 
SIMULATION-HISTORY by adding on new time-slices; changes 
made to the data in a new time-slice are Invisible to 
earlier time-slices, however, the status of any datum can be 
determined In any time-slice, This certainly gives us-' the 
record of the simulation history that we want. Conniver 
also allows any part of the context to be regarded as a 
separate context. The Importance of this Is that the 


context can then be used as the database, or, more 
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precisely, as the working environment, § for some set of 
programs. That Is, the programs In ae given context work 
only with that context as a knowledge base. Thus, we can 
see that the deductive mechanisms of the debugger can "live 
inside" the simulation history by  stmply using 
SIMULATION-HISTORY as thelr context. Furthermore, the 
deductive mechanisms can live [Inside any part of the 
simulation history which they must examine, Thelr world can 
be a single time-slice or a large, program-edited piece of 
the history. 

We will see that this ability to live 
inside arbitrary pieces of SIMULATION-HISTORY Is a_ key 
requistite for the deductive mechanisms of the debugger. 
For the deductive mechanisms to work, they must apply their 
procedurally-embedded knowledge of how to change the course 
of the simulation to carefully chosen parts of the 
simulatton. This’ ts why the simulation history and Its 
Implementation as SIMULATION-HISTORY form such an’ important 
part of the program. In the next section, we will find that 
the SIMULATION-HISTORY representat ton gains further 
Importance when the debugger generates hypothetical states 


of the simulation. 


4.3 Goals and environments 
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Throughout the thesis | have been using 
the word "goal" to describe a varlety of phenomena. ! have 
spoken of user goals, system goals, and submodel goals. In 
section 2 ! Introduced another construct containing the word 


"goals 
(*GOAL <strange words> <numbers> <lots of parentheses>) 


which purported to represent the various other kinds of 
goals to the program. tn this section ! wlll discuss what 
these parenthetical thingees mean to the program. In the 
next section I! will talk about how they are created and 
manipulated. Here ! describe only goals qua *GOAL's--i.e., 
the common structural aspects of *GOAL's. 

A goal expresses a desired state. Ina 
debugging context this desired state [fs almost always 
inconsistent with the actual state. This Is because the 
user has found a discrepancy between reality and expectation 
and has thought of a desired state In which the discrepancy 
is resolved. Thus, the desired state, reflecting the fixed 
discrepancy, fs Inconsistent with the actual state. In the 
program presented here, the user can ask the program to 
produce this desired state (given the model and the 


simulation history--see section 2). (1) The request is made 


(1) As discussed elsewhere, the program falls In Its attempt 
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via a *GOAL statement: 
(*GOAL <achfeve desired state>) 


What does It mean to "achieve the 
desired state"? The user Is asking the program to change 
the course of the simulation. The program goes about this 
by first creating a hypothetical simulation state 
(time-slice) which Includes the desired state. Then it 
attempts to make the rest of the simulation history (l.e., 
the previous time-slices) consistent with the new 
hypothetical time-slice. (1) This Is done by the creation 


of a new *GOAL 
(*GOAL <make previous time-slice consistent with new one>) 
This new *GOAL Is clearly of the form 
(*GOAL <achieve desired state>) 


and can thus be handled exactly l!tke the user goal. The 
program can thus recurse merrily along until [ft cannot 
achfleve a desired state--f.e., until {ft falls. . 

Now then, let's take a closer look at 
to produce the desired state, but this Is not Important to 
the discusston of this section. —— 

(1) This "work backwards" methodology ts due to the 


debugg!Ing philosophy of tracing a bug from Its manifestatio 
back to Its cause. 
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this process. Each *GOAL requests a specific change to a 
specific local environment (the time-slice). Thus, each 
*GOAL Is attempted [In the context of a local constraint 
environment represented by a single time-slice of the 
simulation history. (1) If the *GOAL [Is achieved, [ft will 
define a new environment which is Inconsistent with the old 
time-slice (because of the changes wrought by achieving the 
*GOAL). This new environment ts then consistent with the 
user's destred state, but Inconsistent with the old 
sImulatton history. The program will then use this new 
local environment as a bastfs for defining the next desired 
state along the IlIne toward making the whole simulation 
history consistent with the user's desired state. The 
program ts, in effect, constructing a new hypothetical 
simulation history which results in the user's desired 
state. (2) 

Thus, environments are Intimately 
related to the semantics of *GOAL's. Each *GOAL Is 


constrained by ae pre-specified part of the simulation 


(1) Not quite. As we shall see In a second, multiple goals 
are achleved with respect to a local constrafnt environment 
consisting of several time-slices,. 


(2) The next section deals with the problem of how the 
program constructs this stmulatiton without destroying the 
orlginal intent of the model. Specifically, section 4.4.2.1 
gives a better plcture of what [fs "constraining" about a 
"local constraint environment", 


Page 72 


environment--that part which It Ts supposed to change. The 
achievement of a *GOAL can therefore be seen as a 


transformation: 


initial environment new) environment 


This transformation fs a local phenomenon. However the 
effects of the transformation are non-local. The *GOAL has 
perturbed the local environment and made it inconsistent 
with the global environment. Since the eventual goal of the 
problem solver is to create a consistent simulation history 
which results tn the user's desired state, the global 
environment must be made consistent with this new 


Inconsistent plece: 


initial envivonmestt =e envionment —-Jocired state 
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In order to make the global environment 
consistent, the program must trace down the effects of 
changing that local piece. In other words, it must examine 
the way that local plece Interacts with other pieces of the 


global environment: 


envivonment after one *GOAL envionment after eusel —desived 
'S in One Ine state 


But this fs exactly what we want. The user is incapable of 
following the interactions of the model. If the program is 
to help the user find the “Interactfion bugs" thus created, 
It must have some mechanism for tracing fnteractions. This 
mechanism is the problem-solver. 

The problem-solver uses a *GOAL_ to 
express a global environment perturbatfion. It then uses the 
deductive mechanisms described in the next section to follow 
that perturbation throughout the local environment, the 


local change at each polfnt beltIng determined by a *GOAL. 
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When the program comes to a point where the perturbation 
cannot be continued (f.e., where a *GOAL falls), It has, in 
effect, discovered a part of the environment which cannot be 
made to conform to the user's desired environment. It has 
traced the f[nteractfion path to [ts roots--It has bracketed 
the bug location between the user's desired simulation state 
and the user's deslred constraint which gave rise to the 
Interaction (see 4.4.3). 

Thus, *GOAL's are the vehicle for 
exploring the interactive behavior of the model. As we have 
seen above, the use of *GOAL's In this Way requires 
sophisticated manipulations of local environments. In 
order to tle down some of the concepts discussed [In the 
previous paragraphs, ! will now discuss some of the problems 
the program faces with respect to this environment-handling. 

First, each *GOAL must be achieved with 


respect to a local environment. That Is, the *GOAL must 


oniy see the constraints of a local environment (not the 
whole thing) (1) , and must directly affect only that local 
environment. Otherwise, the distinction between local = and 


Interactive behavior Is _ lost--there fs no such thing as a 


(1) This Is due first to the nature of the problem-solving 
process--"set up a local environment and then make the next 
local environment up the line consistent with [t"--and 
second to the debugging philosophy espoused In 4.4.2.1. 
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"perturbatlon", 

Fortunately, the environment to be 
examined fs the SIMULATION-HISTORY context. We will see in 
4.4.2.1 that the required local environment ts (usually) 


just a TIME-SLICE of the SIMULATION-HISTORY. The *GOAL can 


thus be made to “see" only a local environment by making the 
required TIME-SLICE [Its working environment (as In 4.2) (1) 
' The context structure makes’ the relation between 
TIME-SLICE's evident (1.e., because each Is a Conniver 
layer), so that’ the distinction between . local and 
interactive constraints Is explicit In the bullt-in 
(Conniver) semantics of S!IMULATION-HISTORY. 

Now the *GOAL must also be made _ to 
affect only a local environment tf the semantics discussed 
earlier are to be preserved. It would seem that this is 
just as easy: simply keep the TIME-SLICE [n question as the 
*GOAL's working environment, and al! changes will explicitly 
have the required locality. However, there is a 
complicating factor found in all searching problem-solvers: 
the problem-solver must make provisions for discarding an 


old line of attack and beginning a new one. This Is the old 


problem of backup which has been discussed extensively In 


(1) This tsn't quite so stmple for multiple *GOAL's, as 
we'll see in a second, 
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17! and 119]. 

The backup problem fs_ germane to the 
debugging process because the debugger usually attempts to 
find all possible causes of a particular digcreoaney (In the 
hope that one of them Is the actual bug). Thus, ft will 
follow down one lIne of attack, fall, and try another. It 
must therefore be ready to erase the consequences of the 
TIne to be discarded. But this Is a particularly hard 
problem for the debugger. Here, the tracks leading to 
fallures are the key to the rest of the process, They 
cannot be simple "erased", but must be preserved In some 
form which the program can use to suggest bugs and to 
explain Its actions to the user see 4.4.3), 

Furthermore, while the effects of each 
*GOAL must be resticted to a local environmet, the effects 
of all the *GOAL's must create a new consistent environment 
(1)  . Thus, the program must mafntaln some new environment 
which localizes the effects of the *GOAL's, allows a 
controlled backup with preservation of the backed-over 
Information, and which forces consIistency of ‘all affected 
environments. Certainly, SIMULATION-HISTORY will not do. 

But something like ft will. The program 
again uses a layered-context structure. in each laver it 


(1) They must, In fact, create a new simulation history. 
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records the changes made by a *GOAL to the particular 
TIME-SLICE Involved. It then appends this new layer to 
SIMULATION-HISTORY and uses this new augmented context as 
the working environment of the debugger. Now, remembering 
the little discussfon of context semantics tn 4.2 (or, 
referring to |201!), we see that this causes the following 


effects: 


(1) The effects of a *GOAL are certainly localized 
since they eccur only [In ae single Jayer which 


corresponds to a single TIME-SLICE. 


(2) The debugger can always see a_ consistent 
environment by looking up the augmented 
SIMULATION-HISTORY as far as the Tast affected 
TIME-SLICE; the semantics of context then say that 
the data seen by the debugger [fs just what was in 
SIMULATION-HISTORY before (which Is consistent via the 
simulator) except where contradicted by the parts that 
were changed by *GOAL's (which are consistent (up to 


that polnt) vila the deductive mechanisms). 


Perhaps {ft Is well to Interrupt here with an explanatory 


dlagram... 
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which Is, due to the semantics of context, equivalent to: 


SIMLATION- HISTORY 


which ts certainly an easler conceptualization of what has 
gone on so far. However, the first picture fs necessary to 


explain 
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(3) The layers which record the changes made by a *GOAL 
(the dashed parts of the first picture) can be peeled 
off and saved at any time, thus pestorine. the context 
to Its orfgtnal condition and saving the effects of the 


*GOAL (the track toward falure) for further use 


This methodology fills the bil! so far. Unfortunately, 
there Is one final problem which complicates this Jittle 
picture (you just knew there would be), 

This complicatton comes from an as yet 
unseen aspect of the problem-solver: “multiple goals. ! 
mentfoned earller (section 3) the existence of "higher-order 
constraint Interdependencies" In the model. (This 
welrd-sounding effect was conveniently kept out of the 
example fn section 2.) We will see In section 4.4.2.3 that 
higher-order interdependency leads to multiple goals. That 
is, Instead of simple goals, the program must deal with 


constructs lftkes: 


(*GOAL (#AND 
(#GOAL ...) 
(*GOAL ...) 
(*GOAL ...))) 


and 


Page 81 


(*GOAL (*GROUP 
(*GOAL ...) 
(*GOAL ...) 
(*GOAL ...))) 


We'll see more about multiple goals later. For now we need 
only examIne one aspect of their behavior. 

The ratson d'etre of *AND and *GROUP is 
the expression of the fact that thelr component *GOAL's are 
not independent’: That Is, the *GOAL's they contaltn_ share 
common resources and cannot be achieved at each other's 
expense. (This is how they model I[nterdependency.) Thus, 
the notion of a "local constraint environment" varies from 
the one bandied about earlier. Here we must have several 
*GOAL's sharing a stngle local environment. Furthermore, 
because of the Interdependence of the *GOAL's, a component 
*GOAL that has not yet been completed must "see" the 
constralnts posed by the completion of other component 
*GOAL's. Thus, the local constraint environment might 
cover several TIME-SLICE's. 

Clearly this halrs things up a bit. 
Nonetheless, the program must preserve the semantics of 
these constructs because they are Important effects of the 
model which give rise to thelr own special bugs (see 


4.4.2.3). Actually, given the flexibility of contexts, the 
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Implementation Is rather straightforward. The Tittle 


schematic of environments now looks l1fke: 


, STERULATION” HISTORY 
records of changes Who 
hy goals: n on 
ot may now te 
ee TINE- SLICE ; the trick 
ic in the < <hatig betunen thee 
record layers this determines 
| wl and FGROUP iaterkeyerd- 
“ 
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In terms of the previous discusston of 
perturbations, local and global environments, etc., nothing 
has changed except that the "local" environments now may 


have a halry microstructure of local environments: 


t ier -rdey 
enuironnen 


Uninterested readers may squint at the above picture (and 
concept), leaving everything as before. 

Thus, a *GOAL Indicates a local 
perturbation. The deductive mechanisms of the 
problem-solver follow through the Interactions defined by 
the model to carry the perturbation throughout the 
simulation history in order to _ produce a consistent 
environment. The next section considers these deductive 
mechanisms and thelr interaction (via fallure) with the 


bug-finders. 


4.4 Debugging by problem-solving 
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The basic task of the program ts to 
trace a bug from its manifestation to Its source. This ts 
done by taking In the manifestation as a *GOAL to be 
achteved (as discussed earlier). The process of achieving 
such a *GOAL 1s usually called "problem-solving". But this 
Is a rather special use of problem-solving: the program 
expects to fall in the attempt. In fact, It Is not until 
after a line of attack has failed that It becomes 
Interesting to the debugger. In this section we see how 
ltnes of attack are formed, how they fall, and how they are 
used after they fall. 

The most Important part of any 
problem-solving process Is the formation of subgoals (1) , 
Section a | considers the methods (those deductive 
mechanisms we've heard so much about) for devising new 
subgoals in order to achieve a goal. This corresponds to 
asking the “how could we do this ?" question of section 2. 
But In this program, the object of the problem-solver is not 
this direct attack on the problem, Instead, the 
problem-solver must make certain ft does not change the 
Intent of the user's model In trying to debug it. 


Thus, the process of attacking the 


(1) Especially In this problem-solver. SInce subgoals are 
rarely achieved, the whole process turns Into 
subgoal-formatton. 
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user's goal leads directly Into the problem of separating 
the constraints which are In the simulation history because 
of user Intent from those which are artifacts of unintended 
model operation. At certafn key points In the deduction 
process, the program determines whether or not It should (In 
terms of user Intentions) make the changes required by the 
deductlon. This process of assigning GOOD and BAD REASON's 
to model actton corresponds to asking the "why didn't you do 
this before?" question of section 2. In 4.4.2 we examine 
this REASONing process in terms of the philosophy of bugs 
presented In section 3, 

The REASONing process leaves the program 
with a failed line of attack. This appears as a stream of 
*GOAL's, annotated at each point with the BAD REASON that 
triggered further program action. The program must then 
examine the record of the problem-solver to attach blame to 
the proper offending model part; tf.e., to find the bug. 
This task of post-mortem recrimination ts the subject of 


&.AL3. 


4.4.1 The attack 


Here we examine the problem-solving 


phase of the debugging process. The key. problem-solving 
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task of the program is. to find the proper local changes 
throughout the global environment which will lead to _ the 
destred change. SInce each deslred change [s represented by 
a *GOAL, the problem-solver proceeds by subgoal formation. 

The subgoal-format ion parts of the 
program (the "deductive mechanisms" mentloned earller) are 
responsible for figurtng out how one local change can be 
brought about by another. As an example of the way this 
cause-effect knowledge Is procedurally represented In the 
problem-solver, the INCREASE functlon Is presented here. 
The explanation of how INCREASE works will lead us directly 
Into the REASONing methods of 4&.4.2. 

The program's mafn vehicle for asking 


the "how?" question Is the INCREASE *GOAL: 


(*GOAL CINCREASE <resource variable or submodel> 


<amount> <time-slice> (1) )) 


That is, "goal: Increase the resource variable or submodel. 
by the specified amount In the specifled time-slice." |The 
user's Initial *GOAL Is usually of the INCREASE type (see 
section 2). This just means that the user's dixerenanes Is 


usually a defficlency of some resource varlable (or lack of 


(1) If ae <time-slice> Is not given, the program 
heurlsticaliy chooses one. 
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the appearance of some submodel) which he is asking the 
program to fix up. 

As we saw in section 4.3, the program 
Immediately sets up a hypothetical local environment’ In 
which the deffictency has been rectified. Then It trfes to 
deduce an earlier environment which would cause the new 
desired sitmulation.§ state. It does this deduction via the 
"logic of INCREASE" mentioned In section 2. The "logic", 


briefly stated, runs as follows: 
(1) Constant quantities cannot be INCREASE'd 


(2) In order to INCREASE a quantity that Is a resource 
vartable which Is *OUTPUT (*REMOVE'd) by an *ACTIVITY 
or *EVENT, set up a new *GOAL to INCREASE (DECREASE) 


the number of occurences of that *ACTIVITY or *EVENT 
(3) In order to INCREASE a quantity that Is *RETURN'ed 
by a *FUNCTION, set up a new INCREASE-FUNCTION *GOAL (1) 


(4) In order to INCREASE the number of occurences of an 


“ACTIVITY, set up (If necessary (2) ) a new *GOAL to 


(1) INCREASE-FUNCTION's major claim to fame is that it sets 
up *GROUP *GOAL's. 1 will therefore discuss [ft when ! talk 
about *GROUP In 4.4.2.3 rather than here. For now it's okay 
to view INCREASE-FUNCTION as analogous to INCREASE applied 
to *ACTIVITY's. 
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INCREASE the resources needed by that *ACTIVITY 


(5) In order to !NCREASE the number of occurences of an 
*EVENT, set up a new *GOAL to INCREASE the frequency 
with which its *CONDITIONS are valid (which might 
Include a *GOAL to INCREASE the number of occurences of 


the *ACTIVITY's which the *EVENT affects) 


Clearly, the Intent of this lfst Is to cover anything which 
the user or another part of the program (1) might ask to 
INCREASE. However, the rules In the list are by no means of 
untform character; they differ greatly In their logical 
bases. 

The first rule can be viewed as a 
“fact", or, if you wlll, a property of the concept 
"Increase." That ts, the first rule depends only on the 
concept of "Increase"~-not on MSL, models, etc. The second 
rule expresses a definite property of MSL rooted In the 
semantics of *OUTPUT. It therefore depends not only = on 
"Increase", but also on the definition of MSL. The third 
rule, which will be discussed later, depends on "tfncrease", 
the definition of MSL, and the rules of mathematics (since 
(2) Some necessary resources may already be present In 
sufficient quantlity. 


(1) Stnce INCREASE ts defined recursively, the “other part 
of the program" might be INCREASE Itself. 
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mathematical functfons are being Increased). Agatn, It fs 
valid for any MSL model. The fourth and flfth rules are 
different In a very Important way. They depend not only on 
the definition of MSL and other "givens", but also on the 
particular model defined by the user, 

The reason for this is that the 
occurence of *ACTIVITY's (and thus *EVENT's via_ the 
*ACTIVITIES construct (see 4.1)) can be directly determined 
by user Intentions. These intentftons are expressed by the 
*SCHEDULE modifier (see 4.1). *SCHEDULE is used whenever 
the modeller wishes’ to override the "always schedule when 
possible” default of the simulator, It therefore determines 
the pattern of *ACTIVITY and *EVENT activation throughout 
the simulatfon. *SCHEDULE is thus the primary expression of 
the user's policy for directing the dynamics of his model. 

The fact that the "logic of INCREASE" 
must take Into account user Intention provides the key link 
between the "how?" and "why not?" questions. In the case 
of the first three rules of INCREASE, the "how?" question fs 
perfectly well-formed, The program need only look at what 
is to be INCREASE'd without worrying about reasons why [t 
shouldn't be done. There are no reasons, because the rules 
are valld for any case the program can encounter. Thus, 


the program can always go ahead and try the INCREASE. It 
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can efther fall (1) (as [n the case of INCREASIng a 
constant, for example) or [It can set up the next subgoal 
(usually another INCREASE *GOAL)--all without worrying about 
"Should" and "shouldn't", 

On the other hand, rules (4) and (5) 
must worry about "should" and "shouldn't" before setting up 
the next subgoal. Perhaps the user does not [Intend for the 
INCREASE to take place. Thus, INCREASE must ask the "why 


not?" question before [It proceeds. 


4.4.2 The voice of REASON 


We saw [In the previous section that the 
use of INCREASE to ask the "how?" question leads directly 
to the need for the "why not?" question. As usual, the 
program frames th!ls question as a *GOAL. That Is, given the 
*GOAL of INCREASIng an *ACTIVITY "A" by "m'' occurences’ in 
TIME-SLICE “n''; 


(*GOAL CINCREASE A m n)) 


(1) A fallure of this kind Is automatically for a "GOOD 
REASON"--see sections 2 and 4.4.2.1. 
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the program ftmmediately forms the *GOAL 


(*GOAL (SCHEDULE m A n)) 
to ascertain whether or not INCREASE should proceed. 

SCHEDULE's job Is to examine 
SIMULATION-HISTORY and the user's model to determine why the 
change suggested by INCREASE was not orlgtinally part of 
SIMULATION-HISTORY. After all, since [it presumably leads to 
the desired state, why didn't the user cause the state 
suggested by INCREASE In the first place? 

There are two kinds of reasons for the 
user's not causing the suggested state to occur Initially. 
A GOOD REASON fs that he delfberately Intends (for reasons 
best known to himself) the model not to allow that state. 
A BAD REASON fs that the interactIon of the submodels has 
caused a constraint which disallows the state. A BAD REASON 
Is not a bug. It simply f[mplfies that a constraint is due to 
submodel interaction and not user Intention. However, given 
the bug phllosophy of section 3, the program treats a BAD 
REASON as “suspictous"--a cause for further Investigation. 

| In this sectlon we examine the way the 
program distinguishes GOOD REASON's from BAD REASON's’ (and 
the way It classifies BAD REASON's). The next subsection 


discusses the program's model of user intent--l.e., its 
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method for discerning GOOD REASON's. After this, we 
classify BAD REASON's along the Jtnes’ of the three 


"Interaction bugs" presented In section 3, 


4.4.2.1 GOOD REASON's 


At each stage of the debugging process, 
the program Its trying to change an environment,..by using a 
resource, Inserting a new’ submodel,etc. In order to do 
this, the program must face the question of whether or not 
the change should (tn terms of user Intentions) be made. 
Of course, It Is unreasonable to expect the user to have to 
tell the program at each step what should and should not be 
changed. In fact, given the phllosophy of section 3, [t is 
very unlikely that the user could provide this Information 
If he wanted to. Thus, the program needs some sort of 
theory of which of the constraints found In 
SIMULATION-HISTORY are user-Intended and which are there 
because of a possible bug In the model. 

Golng back to sections 1.3.1 and 3, we 
recall the previous assumptions about user intentions: the 
user has a good understanding of each submodel, but only a 
very weak ubdebebandine of how submodels [Interact to achleve 


an overall goal. Thus, the program can assume, at least 
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temporarlly, that all Information In the sfmulation history 
which fs derived directly from user statements about an 
Individual submodel Is user-Intended. A1Il other information 
Is necessarily the result of submodel interaction and is 
therefore suspect. The programming task fs to interpret 
this simple theory (1) of user [Intention [n terms of the 
deductIve mechanisms and SIMULATION-HISTORY, 

Everything In = an MSL specification 
pertains only to a specific submodel; this, In fact, was a 
design criterion (see 4.1), Thus, everything so far is 
user-Intended, by our principle of locality. But this Its 
only static Information, Once the model Is simulated, some 
of this static local Informatton gives rise to interaction 
between submodels. The question then becomes’ one of 
determing how locality [Is preserved in the dynamic behavior 
of the model. That is, what's local about 


SIMULATION=HISTORY? 


According to 4.3, the answer seems to be 


that the TIME-SLICE fs used by the program as a "local 


(1) This theory fs of course quite lfberal in its suggestion 
of "suspect" constraints. At this stage, this seems to be 
the best strategy. The deductive mechanisms are capable of 
eliminating non-bugs rather easily so that things don't blow 
up (see section 2). However, If really large models were 
used, a better theory would be necessary to avold smothering 
the program with possible leads (see section 4.5). 
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environment".,..but why? The TIME-SLICE preserves’ locality 
because direct user policy Is at the TIME-SLICE level. 
Scheduling decIstons set certain *ACTIVITY's to occur In 
certain TIME-SLICE's (see description of *SCHEDULE [tn 4.1). 
*PREREQUISITES are checked at the TIME-SLICE level, *OUTPUT 
occurs at the TIME-SLICE level, *FUNCTION's are called, 
*EVENT's triggered,etc.--all at the TIME-SLICE level. All 
of the direct user decisions, as specifled by the static 
Informatton In the MSL, affect the simulation at the 
TIME-SLICE level. Therefore, the program takes a constraint 
to be local (and thus user-Intended) [if It depends only on 
what happens In a single TIME-SLICE. 

Now | menttoned In 1.3.1 that the models 
used In this thesis are especially Interactive. 
Furthermore, as t sald above, the criteria for suggesting 
unintended constralnts can afford to be tIiberal--we would 
rather suggest wrong bugs than miss a possible bug. Thus, 
we would expect there to be few local "user-Intended" 
constraints and many non-local "suspect" constraints. This 
is Indeed the case. The resources present In any TIME-SLICE 
are dependent on the action of the model over many 
TIME=SLICE's and are thus non-local. SImilarly, the timing 
of *ACTIVITY's which do not contain *SCHEDULE specifications 


becomes resource-dependent and thus non-local. *EVENT 
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occurences are specified by probabilistic functtons of 
resources and are thus non-local. Finally, higher-order 
constraints l!ke coincident presence of several resources 
span several TIME-SLICE's (see 4.3) and are, almost by 
definition, non-local, These non-local constraints glve 
rise to the BAD-REASON's discussed in the next two 
subsections. For now, let's mention the few GOOD REASON's 
that exist. 

Most GOOD REASON's concern constraints 
that arlse from *SCHEDULE constructs, if the change 
requested by INCREASE would violate the *ACTIVITY's 
*SCHEDULE for that TIME-SLICE, SCHEDULE denies the request 
for GOOD-REASON (1) . Thus, If, as [In section 2, there are 
three ADVERTISING *ACTIVITY's already In a TIME-SLICE and 
ADVERTISING contains the modifier 


(*#SCHEDULE 3) 


SCHEDULE will deny any request to up the amount of 
ADVERTISING In that TIME-SLICE. Sfmllarly, SCHEDULE views 
the other avatars of *SCHEDULE (see 4.1) as 
GOOD-REASON-generators. 

The other kinds of GOOD REASON's are 


(1) There Is one exception to this which will be discussed 
In the next subsection, 
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those that are based on "fact" or are "true by definition" 
(see the first three rules of INCREASE In 4.4.1). Thus, 
SCHEDULE will deny attempts to schedule In negative time, 
increase constants, etc. for GOOD REASON, ‘Actually, these 
REASON's can. be viewed as belIng based on the "common sense 
knowledge" the user has In addition to his knowledge about 
submodels, That Is, the user directly Intends his model to 
be "sensible" as well as to be tn accordance with known 
submodel constraints. 

Thus, GOOD REASON's apply to constraints 
which depend only on single TIME-SLICE information, f.e., 
which reflect the locality which Is characterIstic of user 
Intention, We now go on to Investigate the way In which the 


program deals with non-local constraints. 


4.4.2.2 Basic BAD REASON’s 


If the program cannot find a GOOD REASON 
for a constraint, [It must attribute Its existence to a BAD 
REASON. From the “Interaction bug" philosophy of section 3 
we see that the user's understanding of his model falters in 
the three critical areas mentioned at the beginning of this 


section: 
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(1) the effects of resource competition among submodels 
(2) timing effects of submodels 


(3) the effects of higher-order constraints 


If a constraint Is there for no GOOD REASON, the program 
considers the possibility that the constraint arose 
untntentlonally from one of these three mlsunderstandings. 
It will therefore try to come up with a BAD REASON for the 
constraint's existence so that It can Inform the debugger of 
the possible anomaly (see section 4.4.3). This section 
will consider the BAD REASON's’ related to the first two 
kinds of Interaction, These BAD REASON's form the basis for 
BAD REASON's arising from higher-order liteedapendenctes=-a8 
discussed [In 4.4.2.3, Now, to continue with our favorite 
process, the SCHEDULE *GOAL was just seeing why the desired 
*ACTIVITY wasn't scheduled In that TIME-SLICE In the first 
place... 

Since the user didn't specifically ask 
for the *ACTIVITY not to be scheduled, there can be only two 


reasons why the *ACTIVITY wasn't there: 


(1) some of Its prerequlsite resources weren't present 


Page 98 


(2) It Its dependent on an *EVENT that didn't occur 


Thus, the program first checks out the resource situation tn 
the TIME-SLICE. tf the resources are not. suffictent to 


support the *ACTIVITY, there can be two reasons why: 


(1) the resources were avallable In the TIME-SLICE but 
were used-up by higher-priority *ACTIVITY's before the 


*ACTIVETY In question got a chance at them 
(2) the resources just ain't there 


To check out the first possibility, the program looks at the 
status of the higher-priority *ACTIVITY's In the TIME-SLICE. 
If any of these *ACTIVITY's Indeed "stole" resources which 
would have allowed scheduling of the desired *ACTIVITY, 


their names are collected and the BAD REASON 


| (PRIORI TY-RESOURCE-BOUND (<names of offending *ACTIVITY's>)) 
ts recorded: 

tf no higher-priority *ACTIVITY's stole 
the resources, then the resources must just have been absent 
from the TIME-SLICE In the first place. The ubiquitous 


two possible reasons: 
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(1) The *ACTIVITY's which *OUTPUT the desired resources 
weren't scheduled until ft was too late for the 


resources to be avaflable [In the TIME-SLICE 


(2) The *ACTIVITY's which *OUTPUT the destred resources 
were scheduled too early and the resources were 
gobbled up by higher-priorfty *ACTIVITY's In the 


intervening TIME-SLICE's 


Of course, In elther Instance, the user may have [Intended 
this to be the case (well we know how to check that out...). 
On the other hand, the *OUTPUT #ACTIVITY's may have ended up 
in the wrong place because of the user's poor understanding 
of timing effects (1) --a BAD REASON. To determine which Is 
the case, the program proceeds as follows. It first finds 
out what *ACTIVITY's *OUTPUT the desired resources and 
checks to see If they were scheduled too late to do the 
desired *ACTIVITY any good. Then, ft sees whether the 
*OUTPUT *ACTIVITY's were "late" for GOOD REASON. If not, it 
notes a BAD REASON: 


(1) Note that the "Interaction Information" about timing Is 
Implicit {n the resources. That fs, there are no explicit 
timer-alarms to say when something [s too late or too early. 
The only evidence of a timing error In the model will be 
found In the levels of particular resources over time. 
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(RESOURCE-BOUND (TOO LATE (<names 
of offending *ACTEVITY's>))) 


If there are no “late" *ACTIVITY's, or If the *ACTIVITY's 
were late for GOOD REASON, the program looks back up_ the 
SIMULATION-HISTORY for two things: *ACTIVITY's which *QUTPUT 
the needed resources scheduled "too early" for no GOOD 
REASON and "“tnterloping™ *#*ACTIVITY's of higher prlority 
which stole the needed resources. If both of these things 


extst, the program notes: 


(RESOURCE-BOUND (TOO-EARLY (<names of offending *ACTIVITY's) 
(<names of Interloping *#ACTIVITY's>))) 


Thus, the PRIORITY-RESOURCE-BOUND and 
RESOURCE-BOUND BAD REASON's take care of the case fn which 
the *ACTIVITY cannot be scheduled because of a lack of 
prerequisite resources (1) . Thlis leaves the other case in 


which the *#*ACTIVITY could not be scheduled because [t fs 


(1) As discussed previously, the program would try to 
alleviate this defficilency with an appropriate INCREASE 
*GOAL. The reason for this is to make sure that the program 
traces through the entire interaction path: after all, this 
resource defficilency could just be the result of an earller 
dec!Ision which reflects the actual bug. More on this In 
B43. 
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dependent on. an *EVENT that didn't occur. 
The program can easIly recognize this 


second case because It can only arfse from the 
(*SCHEDULE (ON <*EVENT-name>) ) 


specification (see 4.1). If the specifled *EVENT did not 
occur in the TIME-SLICE, the desfred *ACTIVITY could not be 
scheduled. Now, if the program were acting like it did 
before, it would try to find out "why" the *EVENT didn't 
take place Tn the TIME-SLICE. However, this Is 
inappropriate for *EVENT's, which, after all, model 
occurences which are beyond the modeller's direct control. 
Of course, this ralses the question of why a modeller would 
make an *ACTIVITY dependent on an *EVENT in the first place. 
Indeed, the program becomes suspicious: it Is possible that 
because of the user's poor understanding of timing effects, 
the *EVENT dependency (plus the time needed by _ the 
*ACTIVITY) will cause the *ACTIVITY to take effect at the 


wrong time--usually too late (1) . The program checks out 


(1) The most common cause of this *EVENT-dependency Is the 
"“flre-flghting" approach to solving problems: when the event 
occurs, start doing something about It. (This. Is, In fact, 
the problem in the example of section 2: HIRING [Is dependent 
on QUITTING.) Note that this BAD REASON fs the exception 
to the "If *SCHEDULE says It's okay, It's okay" dictum 
referred to earller. 
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this possibility by looking up and down SIMULATION-HISTORY 
to see If the *ACTIVITY was scheduled "too late" or "too 
early", 1f either of these Is the case, the program notes a 


BAD REASON: 


(*#EVENT-TRIGGERED-SCHEDULE <offending *ACTIVITY> 
<"TOO LATE" or “TOO EARLY") | 


If nefther of these Is the case, the program stImply 


terminates Its lfne of attack (1) on 
(*EVENT-TRIGGERED-SCHEDULE) 


and goes away mumbling to Itself (actually, this would be 
the first “GOOD REASON" It looks at after all the BAD 
REASON's were checked by the debugger). 

Well, this wraps up the “basic BAD 
REASON's" artsing from poor understanding of resource 
conflict and timing effects. Now. we go on to. see _ how 
misunderstanding of higher-order constraints leads to the 


use of these same BAD REASON's In an expanded context. 


(1) Note that unlike the other BAD REASON's, this one causes 
the lIne of attack to terminate--no further Investigation Its 
possible (see 4.4.3), 
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4.4.2.3 Higher-order BAD REASON's 


Up until? now (except for part of 4.3), | 
have over-simplifled the [Interactive behavior of submodels 
for the purposes of discussion, Specifically, I have 
pretended that a submodel can depend on only one other 
submodel for fits sources of Input. Thus, my *ACTIVITY's 
have had only one unfilled *PREREQUISITE, my *FUNCTION's 
only one *ARGUMENT. This ts of course quite unrealistic, 
and not a real restrictlon of MSL. In this section | remove 
this artificial restriction. 

The tntroduction of multiple dependency 
brings up the issue of higher-order constraints. As we saw 
in 4.3, when submodels depend on several other submodels for 
Input, the problem-solver must take [nto account the 
Interrelationship of the [Input *ACTIVITY's. The input 
*ACTIVITY's are In fact operating under a "higher-order 
constraint" (see section 3,2)--they must combIne to provide 
resources for a single *ACTIVITY (or *FUNCTION) at a certaln 
time . This higher-order constraint Is modelled by forcing 
the Input *ACTIVITY's to share a local constraint 
environment (see 4.3). That is, all *ACTIVITY's sharing a 
higher-order constraint must be scheduled not only in 


accordance with thelr own needs, but also with the needs of 
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the #ACTIVITY or *FUNCTION that depends on them. There are 
two types of environment-sharing, reflected by two types of 
*GOAL's to handle the higher-order dependencies. The first 
of these Is *AND, the expression of the way *ACTIVITY's 
depend on each other when their higher-order constraint Is 
another *ACTIVITY. The second [s *GROUP, which models’ the 
*ACTIVITY-*FUNCTION dependency. 
*AND dependency arlses from *ACTIVITY's 
that look like 
(#ACTIVITY SALES-CALL 
(*PREREQUISITES 
(*AND 
(*PRESENT (1000 CASH) ) 
(*PRESENT (1 UNIT) ) 


(*PRESENT (SOME 
SALESMAN) ))) 


e 


- ? 


That is, SALES-CALL depends on the submodels which *OUTPUT 
CASH,UNIT, and SALESMAN. All of these *OUTPUT's must be 
present at once (f.e., In the same TIME-SLICE), Thus, any 
*GOAL which tries to schedule a new SALES-CALL *#ACTIVITY 
must take this Into account. Specifically, If the resources 
are not avallable, all of the *OUTPUT *ACTIVITY's Involved 


must be scheduled. That fs, given the *GOAL 


(*#GOAL CINCREASE SALES-CALL m n)) 
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and assuming none of the necessary resources are on hand (1) 


, the program must generate the subgoal 


(*#GOAL 
(#AND 
(*GOAL CINCREASE CASH j n)) 
(*#GOAL CINCREASE UNIT k n)) 
(*GOAL CINCREASE SALESMAN 1 n)) 
)) 


Now, just as before, the program must be 
careful not to INCREASE things contrary to the intentions of 
the user. Agatn, It uses the SCHEDULE *GOAL to find out the 
REASON for constraints. However, the SCHEDULE *GOAL cannot 
simply check out each INCREASE *GOAL independently as 
before. The INCREASE *GOAL's are now interdependent and 
must be treated as such, So now, finding Goon and BAD 
REASON's Is a whole new game. 

Not really. Fortunately, the process 
isn't very different, especially In the case of *AND. First 
of all, examination of the whole GOOD REASON-f iInding 
philosophy and implementation will show that it Is 
completely unaffected by higher-order Interdependencies. 
This Is almost by definition: GOOD REASON's pertaln to 
Individual submodels and TIME-SLICE's, while higher-order 


(1) In section 2 | kept higher-order constraints out of the 
picture by buffering away dependencies. Thus, In the case 
of SALES-CALL, all resources except SALESMAN were avaflable 
already (see section 2). 
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Interdependencles transcend these boundarfes of locality. 
Thus, SCHEDULE's GOOD REASONIng processes are still the 
same. Certainly, however, the BAD REASONIng is different. 
But most of the differences have been taken care of already 
by the environment-sharing discussed [n 4.3, That Is, the 
effects of higher-order constraints on resource conflicts 
and time dependencies are already reflected [In the way *AND 
*GOAL's are set up and processed--the higher-order 
interdependency Is already modelled. For. example, if 
satisfying one component *GOAL steals resources from another 
or disturbs the timing of another, the shared environment 
will make this Interaction explicit: the resources needed by 
each *GOAL are recorded separately so that the effects of 
everything done in the *AND environment can be traced to the 
proper source. 

All this Is saying that all SCHEDULE has 
to do about *AND's is to realize that [It is tn a_ shared 
environment and attribute BAD REASON's to the effects of 
sharing. Thus, the searches for higher-priority *ACTIVITY's 
and timing problems which were previously carried out only 
In a single TIME-SLICE are now carried out [In the whole *AND 
environment. The "new'' BAD REASON's they generate look like 


(PRIORITY-RESOURCE-BOUND (<names of offending 
*ACTIVITY's>) *AND-MODE) 


CRESOURCE-BOUND (TOO-EARLY (<names 
of offending *ACTIVITY's>) 


Page 107 


*AND-MODE (<names of Interloping *ACTIVITY's 
In the *AND envfironment>) (<names of other 
interloping *ACTIVITY's>)) 


etc. 


The theme here fs that most of the work 
for finding higher-order BAD-REASON's in the *AND case was 
done by setting up the *AND environment in the first place. 
That Is, the Interdependency Is already explicitly modelled 
by the way *AND *GOAL's work, and need only be checked 
through by SCHEDULE to find the appropriate BAD REASON's. 
This theme fs elaborated for the *GROUP case. 

| In 4.4.1 1 postponed the Issue _ of 
INCREASIng *FUNCTION's by attributing this task to a 
separate INCREASE-FUNCTION *GOAL-type. The job of 
INCREASE-FUNCTION Is to figure out a way to Increase’ the 
value *RETURN'ed by a *FUNCTION by changing the values of 
Its *ARGUMENTS (thus, ft is completely analogous to 
INCREASE). Obviously, this problem fs extremely difficult 
for a large class of functions, Fortunately, the functions 
needed [In business games, and, indeed, In most of business 


processing, are of a very simple nature (1) . MSL currently 


(1) The mathematics of management sclence--!.e., mathematics 
meant to model systems) and decislons--can be quite 
sophIsticated, but this fs not business processing. Indeed, 
even in a business game, the probabfllty-handling can get 
tricky. But all of this fs built Into MSL--the user’ can 
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allows the representation of only two kinds of functional 
dependencies: tables - and YInear functions of aie few 
varlables. The mathematical techniques for Increasing these 
*FUNCTION's are simple and are not of Interest here. The 
Interesting part of *FUNCTION's for this discussion Is they 
are responsible for the second kind. of higher-order 
interdependency. 

We just saw how the relation between 
*PREREQUISITES and *OUTPUT's causes *AND Interdependency. 
Stmilarly, the relation between *ARGUMENTS and *RETURN'ed 
value causes *GROUP fnterdepency. in the *AND case, the 
Interdependency was that al] *PREREQUISITES must be present 
In the proper quantities In a single TIME-SLICE for the 
*ACTIVITY to be Inittated. *GROUP Interdependency.§ is 
weaker, We know only that some combination of changes to 
the components will bring about the desired change to the 
higher-order constraint. That Is, each subgoal can 
contribute an unspecified amount to the success of the 
overall *GOAL. Perhaps the Increase of only one of the 
*ARGUMENT resources will suffice to Increase the *RETURN'ed 
value. Or, all may be necessary-~~making the *GROUP an *AND 
at the extreme. 

Now the program must model this kind of 


only define simple functions which use the probability 
machinery. 
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interdependency when it tries to INCREASE *FUNCTION's. 
Furthermore, in trying to solve the INCREASE-FUNCTION 
problem, ft must go about the task pretty much the same way 
organizations do In order to run’ [nto the same kind of 
Interactive behavior. That Is, the Interactlon Involved fn 
a kind of breadth-flrst approach to the problem (increase 
each * ARGUMENT resource a little In turn until the 
*RETURN'ed value has been INCREASE'd the desltred amount) 
causes very different subgoal interaction than, say, a 
depth-first approach (Increase each *ARGUMENT as much as 
possible separately to see how much [t helps to INCREASE the 
*FUNCTION). The differences are [fn which subgoals are 
allowed to be achieved at the expense of others (1) , the 
range of subgoals tried, and the extent to which each 
subgoal Is exercised (2) . Clearly, different 
fnterdependencles are tapped by different subgoal attack 
methods. 


So the program must try to overcome” the 


(1) Unltke *AND, thts fs allowed because not al] *GROUP'ed 
subgoals must be achieved. The only requirement fs that all 
of the subgoals which eventually succeed must share the same 
local constraint environment (otherwise the construct 
doesn't model higher-order interdependency). 


(2) Note that this need to model the organization's 
problem-solving method was not present in the *AND case. 
Sftnce all subgoals must be achieved as stated, no 
"“resource-stealing"™ Is allowed among them and all of them 
must be fully tried and executed. 
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higher-order constraint of Increasing a 
functlonally-determined value the same way organizatlons do. 
Obviously, this is a tall order. First of all, functional 
relationships are usually f[mplicit In organizations, not 
explictt as In MSL--so It's hard to see what organizations 
do about them. Second, [t Is reasonable to assume that 
different organizations attack different functional problems 
In different ways at different times. Finally, ft Is 
possible that the actual process {fs not pre-defined at all 
In many cases, but Is Instead made-up and modiffed during 
the course of each problem's solution. What | am trying to 
say by all of this Is that I'm not about to solve the whole 
problem or even a very big part of it... 

What | have done Is to program a single, 
sltghtly sophisticated method of attacking higher-order 
functional constraints which attempts to model one way in 
which an organization might do [t. Itt should be seen as an 
experiment for demonstrating the approach of the program In 
dealing with this kind of constraint, not a fully developed 
plece of the system. This part of the program, Incorporated 
In INCREASE-FUNCTION, works as follows: given a *GOAL of the 
form 

(*GOAL 
(*GROUP 


(*GOAL CINCREASE argumentl timel)) 
(*GOAL (INCREASE argument2 time2)) 
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)) 
the program takes the first *GOAL 
(#GOAL (INCREASE argumentl timel)) 


and tries to INCREASE argumentl the minftmum possible amount 
as a "Feasibility study", It carries the *GOAL all the way 
to completion, if ft can. If the *GOAL fs unsuccessful 
(for GOOD REASON), [ft [fs withdrwan from the *GROUP and the 
program does a “feasibility study" on the next *GOAL in the 
*GROUP, If no "feasibility study" Is successful, the whole 
*GROUP naturally falls. Now, If any of the "studies" are 
successful, the program will keep attacking the studied line 
until it falls. When this happens, I.e., when the 
particular *ARGUMENT has been INCREASE'd as  ~much~ as 
possible, the program considers Itself to have a "partial 
success", That Is, the effect of the INCREASE'd *ARGUMENT 


Is now calculated [nto the overall *GROUP *GOAL, so that a 


new *GROUP *GOAL Is formed such that 


(1) The fully INCREASE'd *GOAL ts no longer In_ the 
*GROUP 


(2) The overall *GOAL is reduced by the amount 


contributed by the successfully INCREASE'd *GOAL 
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In this new *GROUP environment, the other *GOAL's are 


simtlarly processed unt 
All of this hopefully goes toward 


11 success (or faflure) occurs. 


modelling the way an organization attacks this kind of 
problem: by checking out and eliminating possibilities one 
by one, and pushing winntng lines as far as possible to 
achleve the overall *GOAL. As Intimated tn 4.3, the process 

is modelled (like *AND) by the proper sharing of 
environments. Obviously, the environment-hackery for 
*GROUP's fs a bit more complicated than for *AND (for 
example, It must Incorporate the notfon of “partial success" 
and the fact that all the eventually successful *GOAL's and 
only the eventually successful *GOAL's share the same local 
constraint environment). The question for us here Is how 
this affects the GOOD and BAD REASONIng process. 

Again, the answer Is "not all that 
much". As with the *AND case, the only difference Is that 
the BAD REASON's differentiate between constraints caused by 
higher-order interaction and those caused by other kinds of 
interaction. This Is again just a matter of tracing through 
the explicit relationships set up In the *GOAL's environment 
structure, As far as actual BAD REASON! s for constraints 
go, *GROUP only adds two (minor) new wrinkles. First of 


all, It will make a special notation ftf the constralint comes 
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up during a feasibility trial. Second, {t carefully notes 
which *GROUP *GOAL's have already succeeded when the 
constraint comes up. These are just convenience’ factors 
which the bug-finder uses when suggesting *GROUP bugs to the 
user; {It wants to make clear exactly what the program was 
doing when {ft ran [nto the constraint. This ts Important, 
because, as mentioned above, different interaction occurs 
depending on exactly what the program does, 
| This brings up a final [important point. 
*GROUP BAD REASON's are perhaps the weakest In the REASON 
repertolre because they depend directly on the actual 
exploration methods’ used. That Is, the program might 
suggest a BAD REASON which the user may never really 
encounter because of the way his organization handles 
functional dependencies. Thus, the debugger saves 
*GROUP-type bugs for last. Nonetheless, ! think that it Is 
very Important to Include this kind of REASONIng fn the 
debugger: *GROUP-style dependencles are pervasive In 
organizations. Furthermore, they pofnt the way toward 
modelling more sophisticated kinds of submodel-submodel 
Interactions . The weakness of the *GROUP method In this 
program Is Its Incompleteness, not {ts basIc concept, 
Thts section has catalogued all of the | 


BAD REASON's generated by the program. Now we finally get 
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around to finishing the bug story by showing how the BAD 


REASON's are used to suggest the actual model bugs. 


4.4.3 The post-mortem recriminations 


So far, the debugger has been left with 
a bunch of GOOD and BAD REASON's for constraints. It Is now 
time to turn these Into bug suggesttons. So, let's see what 
the REASON's mean to the debugger. If the problem-solver Is 
faced with a BAD REASON for a constralInt, It knows that’ the 
constraint Is based on submodel interaction. Its job fs to 
explore that Interaction. Therefore, when SCHEDULE returns 
a BAD REASON, the problem-solver considers It a cause for 
further Investigation. In this way, It carries the 
perturbation as far as It can--tracing the Interaction 
patterns to their roots. 

GOOD REASON's are the "roots" that stop 
this search through the interaction path. They imply that 
the constraint blocking the path Is not due to Interaction, 
but rather to direct user Intent. The program should not 
disturb user Intent, since fits only purpose In changing the 
environment [Is to debug the existing model. It now has a 


GOOD REASON to stop changing the environment, so it stops. 
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Its current line of attack Is said to "fall" (in its attempt 
to bring about the destred change). Thus, the 
problem-solver's activities leave a line of *GOAL's attached 
to BAD REASON's ending In a *GOAL attached to a GOOD REASON 
(1) . Now what does all of thls have to do with debugging? 
Simply this: the program has now tried to overcome every 
Interaction-based constraint In the way of producing the 
user's desired state. ft has reached a_user-desired 
constraint which fs the root cause of all of the 
Interaction-based constraints. Therefore, it has reached 
the end of the line and cannot produce the user's desired 
state. There can be three reasons for this. state of 
affairs: 


(1) The user's desired state its off-base: he has. set 
the model an fmposstible task 


(2) One of the user's orlginal Intenttons Is wrong; 
t.e., one of the root constraints Is the bug 


(3) One or more of the f[nteractlon-based constraints 
between the root constraints and the desired state are 
Incorrect: the model has an Interaction bug 
It is obvious from what has been satd before that the 
program thinks that possibility (3) is the most likely. It 


therefore suggests that one or more of the interactive 


constraints (noted by BAD REASON's) are caused by the bug. 


(1) Except for the *EVENT-TRIGGERED-SCHEDULE case discussed 
In 4.4.2.3. 
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That fs, given that the Interaction constraints are wrongly 
caustng the discrepancy, the debugger's job Is to find the 
part of the model which gives rise to the faulty 
constraints. This is then suggested as the "bug" In the 
user's model. If the user doesn't agree with. any of the 
program's suggestions based on possibility (3), the program 
falls back on (2), and finally (1). Anyway, let's pick up 
the process again at the possiblity (3) suggestion phase. 
The program now has the location of the 
bug bracketed between the beginning and end of a "line of 
attack". Furthermore, the submodels which could have caused 
the bug have been narrowed down toa relatively smalll 
"Interaction group" (the unlon of all submodels mentioned in 


the bracket) (1) . The program must now pick out the 


(1) The stze of the "bracket" and “Interaction group" of 
course depends on the model. However, [In the experience |! 
have had, the relevant groups have been small:.a few BAD 
REASON's and thus slightly more possible submodels. In the 
case of higher-order stuff, the group gets somewhat larger. 
There ts no reason to expect brackets or interaction groups 
to get much larger for larger models: the key factor In 
determining thelr sfze fs the amount of control the user 
exercises over his model (fn MSL, the extent to which things 
are determined by *SCHEDULE's). Control means GOOD REASON's 
and thus short paths between [Initial manifestations of a 
discrepancy and GOOD REASON's to close the bracket. Control 
also means smaller groups of submodels which can affect the 
timing and resource~allocation of other submodels. Stnce 
managers (and modellers) exert considerable control over 
thelr systems, the amount of uncontrolled Interaction 
possible Tn any realfstic model ts probably quite 
reasonable-sized. This In turn means that brackets and 
Interaction groups should also stay reasonable-sIzed. 
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submodels in the "group" which caused the BAD constraints In 
the “bracket", 

Sometimes this is quite easy: all of the 
BAD REASON's are traceable to a single submodel Interaction. 
Examples of this are the *EVENT which triggers an *ACTIVITY 
at the wrong time, the *ACTIVITY which constantly steals 
resources from other necessary *ACTIVITY's, and the 
*ACTIVITY which Its always too late (too earty) to allow 
another *ACTIVITY to be Initiated on time. The program 
looks for these sIingle-cause Interactions by scanning the 
BAD REASON's tn the bracket, looking for "give-away" BAD 
REASON's 1l!ke *EVENT-DEPENDENT-SCHEDULE or conststencies In 
the “offending *ACTIVITY's" and "interloping *ACTIVITY's" 
listings. If, In the process of examining the bracket, the 
debugger finds a single such cause for the BAD REASON's of 
the bracket, it Immediately labels the faulty interaction 
(Il.e., the submodels Involved in the interaction) as the bug 
for that bracket, and files it away. Often, however, in 
looking at the BAD REASON's of a bracket, the program finds 
that a particular BAD REASON could have been caused by any 
of several interactions. For example, *ACTIVITY A couldn't 
be scheduled because B_ stole Its resources, or because C 
caused D to be late so that D couldn't provide the necessary 


resources for A. The program handles this by noting each 
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cause separately as a bug. 


Sometimes this straightforward process 
breaks down: the program Is unable to pick out the cause for 
the BAD constralints of a bracket (this — heaeens mostly In 
*AND's and (especlally) *GROUP's). Currently, the program 
simply presents the troublesome bracket to the user telling 
him that "there's something wrong In there", | consider 
this an incomplete part of the program (see. 4.5). 

When the program has found the bug (or 
the few bugs) for each bracket, It presents them to the user 
In order of "likelthood". The debugger's model of the 
likelfhood that a suggested bug Is actually a bug In the 


model ts 


(1) The more specific the suggested bug, the more 
Ttkely fit Is that [ft Is genulne; thus, bugs IIke 
*EVENT-DEPENDENT-SCHEDULE which correspond to a_ single 


BAD Interaction are suggested first. 


(2) The. more definite a suggested bug, the more Ifkely 
it Is; t.e., brackets which contaIn a_ single possible 
bug are suggested before those with multiple bugs, 
which are In turn before those which are just brackets 


with the "something's wrong" tag. 
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(3) The more fnteractfions encompassed by a single bug, 
the more lfkely fit Is; this fs just a recursive 
application of Murphy's law...the more’ interaction 
decisions a user has to make, the more he'l? blow--thus 
*AND bugs (1) and long timing chaln bugs (A was late 


for B was late for C was...) come early. 


(4) Timing bugs are more lftkely than’ resource-conflict 
bugs; PRIORITY determinations are much closer to local 
specifications, and are thus more Iifikely to be 
user-intended than the multi-TIME-SLICE machinatlons of 


a timing bug. 
(5) *GROUP bugs are saved for last. 


(6) After all of the bugs due to Interaction are’ gone, 
the program works on the_- second possibility stated 
above--I.e., it starts suggesting that the GOOD 
constraints are faulty Ct.@¢, wrong * SCHEDULE 
specification, etc.); it starts with the 
*EVENT-DEPENDENT~*SCHEDULE GOOD REASON if It's 


around--Ift's suspIclous. 


(1) *GROUP bugs would be here too, except, as | mentioned in 
4.4.2.3, for the fact the mechanism for handling them Is 
rather dublous. 
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Thus, the program goes through Its suggestion repertoire bug 
by bug, providing the user with an ocdeely statement of what 
the program thinks might be wrong with the model (see 
section 2 for the format of the suggestions). The user can 
always ask to see the Interaction path leading to a bug, the 
bracket of a bug, and any other bugs which pertain to a 
particular bracket. 

If the user does not agree with any of 
the bugs suggested, the program will suggest ‘possibility 
(1): that his original *GOAL was wrong. If the user is 
still unsatisfied after all this work, the - program Informs 


him as to the location of his head and togs him out. 


4.5 Don't confuse me with the facts 


Most of the program's knowledge about 
models Is contained In Its conceptions of MSL (Including, 
for example, Its tdeas of how to INCREASE MSL quantities) 
and its notfons of user Intentlon--as discussed [In 4&.4. 
However, as | mentioned in section 2, It Is useful from a 
debugging point of view to Include actual "world" knowledge 
of business games. Clearly, this knowledge can be used to 


suggest bugs which transcend the MSL specification. 
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This Is, In fact, the only use the 
current program has for WOBG knowledge. As shown In section 
2, the program has a facllity for suggesting "missing" parts 
of an MSL specification. This comes from a (very simple) 
model of what an MSL model of a business game (1) could 
contain. The program simply checks at varlous points to 
see whether the addition of an *ACTIVITY could solve some 
problem (usually alleviate some deffictency) in the user's 
model. Thus, when there Is a lack of CASH In the sample run 
In sectlon 2, the program notes that the addition of a 
FACTORING *ACTIVITY (see description In Appendix A and 
specification In Appendix B) could solve the problem. 

While this sort of thing is certainly 


"Zeroeth order" attempt at using world 


useful, It fs only a 
knowledge In debugging. A more fmportant use of WOBG 
knowledge would be to ald in finding bugs within the MSL 
spectfication (i.e., the same kind of bugs the program now 
finds). As | mentfoned In &.4, a major determiner of the 
efficacy of the debugging program Is the number and size of 
the "brackets" which enclose possible bugs. In the current 
program, brackets are determined by the amount of 


uncontrolled interaction--i.e., a purely MSL-level 


criterion. In a more thorough-golng approach, WOBG 


(1) In fact, It Is based entirely on the game in Appendix A. 
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knowledge could be used to determine which interactions are 
really natural and which are possible bugs (1) --thus 
limiting or even eliminating brackets. Also, WOBG knowledge 
could be used to suggest suspiciously specified *ACTIVITY's, 
etc, 

The main reason that | have not 
exploited WOBG knowledge [n these more sophIistIlcated ways Is 
that ft has not been necessary for the models ! have 
investigated so far. Furthermore, It fs Interesting to see 
how far a "domain-independent" (2) debugger can go toward 
finding bugs in MSL models. Thus, WOBG knowledge does not 
enter Into the matin bug-finding process at all. Its sole 
use is In suggesting the addition of *ACTIVITY's to the 


current model (3) . 


(1) This sort of thing Is actually found to some degree in 
the programs of Sussman 118] and Goldstein [5|. 


(2) See Sussman's discussion of the domain-independence of 
HACKER |]18]. 


(3) It operates off a WOBG database which will not be 
described here. It works a lot lfke MAPL [10], and was In 
fact designed to be compatible with the larger MAPL database 
of Protosystem | (the WOB |91). 
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5 Conclusions 


! would JIfke to use this concluding 
section to fit my model-debuggiIng system Into the "big 
picture", viewing [It flrst as a debugging tool, and second 
as part of an automatic programming system. 

The approach of my debugging system 
should be seen as one method of the several which can be 
used by the human or machine problem-solver. The 
simulate-and-Investigate technique shown here is useful for 
debugging poorly understood but eastly modelled systems. It 
requires the modeller's knowledge and lack of knowledge to 
be of a certain character, as outlined earlier. It Is also 
most useful for handling highly Interactive systems. If the 
problem domain Is very well understood, or If actfons in ft 
are basically Independent, other techniques are simpler and 
much better. 

Furhtermore, [{t should be stressed that 
the debugging methods of the program are quite nafve in the 
context of a real (1l.e., non-game) [Interactive system. It 
Is almost certain that all of the techniques described here 
would have to be shored up with procedures based on 


knowledge of the problem domain (see 4&.5). Remember that 
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the basic "smarts" of my system is fn the exploration of the 
stimulation history. In real life, this exploration phase is 
usually preceded by some knowldgable guess work on the part 
of the debugger: almost all expert human debuggers 
(programmers, consultants,etc.) start thelr exploration for 
a bug with a good preconcelved notion of the nature of the 
bug. This "notton" comes from the utIlfization of long 
experfence about what kind of bugs are attached to what kind 
of problems; most debuggers know that only one or two things 
could possibly cause a bug at any given time In their 
exploration. No one yet knows how to encode this’ key 
experfentlal knowledge into a computer program. Certainly, 
no attempt has been made In this thesIs. 

Thus, the program presented here, when 
viewed only as a general debugging technique, should be seen 
as part of a larger system: it fits In after an fnittal 
"guesswork" phase (as one of several possibly applicable 
techniques) and just before a “weeding out" phase which 
makes thorough use of knowledge in the problem domain to 
narrow down the choice of possible bugs. 

The model -debugg ing needs of an 
automatic programming system are somewhat different. Here 
the user Is Interested In expressing a model of his problem 


to the machine In such a way that he can be sure that the 
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machine understands Jt properly. Thus, after a phase of 
mode! specification atd at define-time (1) ; a 
model-debugging system JIIike the one here can come [n and 
demonstrate the APS's Idea of the model to the user's 
satisfaction (and help the user overcome any dicrepancys). 
The simulate-and-Investigate and domaIn- Independence 
philosophies of my system are well-adapted to this purpose: 
the system can afford to be an expert In its own modelling 
language and do a great deal of exploration work In finding 
bugs. Furthermore, the user can tolerate a_ reasonable 
number of program~generated cholces of bugs In his model If 
he can be certain of eventual understanding by the APS. 
Therefore, ! think that the techniques used here might find 
direct application tn automatic programming. 

Nonetheless, for a debugger to be truly 
useful, whether tn an automatic programming or general 
artifictal Intelligence environment, It must Incorporate the 
same kind of experlential debugging knowledge found In the 
human expert. This kind of stuff will surely be the basis 
of the next generation of debuggers which are now on the 


horfzon. 


(1) See 19] for Protosystem I's “activity expert modules". 
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Appendix A 


The following Is excerpted from the 
article "Bustness Games--Play One!" by G.R. Andlinger In the 
Harvard Bustness Review for March-April, 1958 (¢ The 
President and Fellows of Harvard Untiversity)--ft Is 
reprinted by permission. 

: !t serves as an example of the kind of 
business games at which the program (and MSL) are directed. 
An MSL model of the game described here appears In Appendix 
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Business Games--Play One! 
BastIc Objectives 


Games are as old as man. Usually, thelr 
basfc objective Is entertainment. The Bus!tness Management 
Game, however, alms not at entertainment, but at learning. 
Other differences between It and a game like Monopoly, for 
example, are: 

‘'=-The degree to which {ft approaches reallty. 


--The degree to which the players' 
experflence, judgment, and skill--as opposed to luck-- 
Influence the outcome. 

if any business game [s to serve a purpose beyond 
that of a fascinating toy , there must be some transfer of 
learning from the game sItuation to reallty.. While there 
probably [Is some. such transfer from playing a generalized 
business game that mirrors "any company" and not a 
particular firm, an executive could derive infinitely 
greater benefit from a game that permits him to practice 
gulding the destiny of his own company or one In his own 
Industry~-which unfortunately, Is unavallable at this early 
stage of business gaming. The success of specific war 
games, which the military has been using for years to 
simulate combat sfituatfons for training officers, however, 
holds great promise for sftmilar applications fn busfness’ In 
due course. 

The Bustness Management Game Is a case 
In pofnt. We started It In 1956 with the fdea of applying 
war-gaming techniques to business. In the course of the 
year we tested, modified, and retested the game many times 
to develop a fine balance between realism and playability. 
The more closely a game _ resembles reality, the more 
cumbersome [ft becomes--unti] It fs no. longer playable. 
Hence, there Is a need to compromise. Also, we desligned 
the game to be relatively stable. No extreme strategy can 
result in sudden success; yet players can gain outstanding 
success If they are good enough--or bankruptcy If they are 
not careful. 

The game fs partly deterministic and 
partly probabilistic. Some results are determined directly 
by the actton of the players; others are, to varying 
degrees, subject to chance or probability. The weight of 
the elements of the game [Is such that the longer the game, 
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the smalller the influence of luck, 
Rules of Play 


In this sectton ! shall give a brief 
general description of each game element and the specific 
values, rules and probabilities that define each element [n 
quantitative terms. Instructftons for the umpltres are 
Included at each polnt; but remember that they should not be 
given to the players. 


The Market 


The market fs made up of 24 customers. Each 
customer's potential fs different; In any one time perlod, a 
few customers are not buylIng any units, while others may buy 
four or five untts (at $10,000 per unit) If a salesman is 
able to make a sale. 

The market is dynamic, so the customer 
potentials change. I!f the market fis growing, they change 
upward; should the market be hit by a recession, however, 
they may drop. drastically. The long-term. trend of the 
market Is announced to the players; short term fluctuations 
are not. If a company Is Interested In finding out what the 
total market potentfal Is In any time perfod, a $2000 
expenditure for market research will buy this Information 
from the umpires. 

The 24 customers divide geographically 
Into four regions on the game board, each region contalning 
six accounts. This geographical division allows the company 
to do local advertising (see the sectton on “Advertising the 
Product") and conduct market research tn only one regton at 
a time. Such market research, which tells a company the 
potential of each customer [In the region and permits’ the 
pinpointing of the direct selling effort (see the section on 
"Marketing the Product"), may be obtatned by paying the 
umptres $30,000 for "staff work." 

In additton to the separation Into 
geographical regions, the market breaks down into one rural 
and two urban markets. The significance of this distinction 
Is that In an urban market, where a salesman can make _ more 
calls per day, he has two chances of making a sale during 
each time perlod, while In the rural market he has only one 
chance. 

If at the end of a year a company 
desires to find out what portion of the total market [It has 
been able to capture, ft may but aie share-of-market 
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Information from the umpires for $2000. 
The umpfre should: 
(1) Keep a lfst of all current account potentlals. 
(2) Distribute a total customer potential, which 


comes to $360,000 at the beginning of the game, at random to 
the 24 customers as follows: 


1 account $40,000 
3 accounts 30,000 
5 accounts 20,000 
13 accounts 10,000 
2 accounts 0 


(3) Depending on the economic climate determined 
In advance, change these starting potentials as the game 
progresses as follows: 


--For slow growth, chane one account each quarter 

at random. Move ahead on the random number table 
a number between 01 and 24 appears, then add 

$10,000 to the potential of that account number. 


--For faster market growth, change two or three 
accounts [In the same mannner as above ffor each 
quarter. 


--For a depression, change half or all of the 
accounts to zero for one or more quarters. 


(&) If a company decides to buy market Information 
(total potentlal, market research, or share of market), 
write the Information on a slip of paper and pass It to the 
company. 


MarketIng the Product 


Units are sold by salesmen, who call on 
the 2h accounts In the market. In an urban market a 
salesman may make two calls per quarter; and [In ae rural 
market, only one. 

In the presence of an umpire, the sales 
manager of a company polnts to the accounts he wants to call 


on. The umptre will tell him, after examining the random 


number table, whether a sale Is made or not. How many 
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units are sold to a customer will depend on competitive 
action. The completed decision form, returned to _ the 
company at the end of the particular perlod, contains’ the 
actual sales results by accounts. 

Whenever a salesman has two calls, he 
must make the second call ona any of the three to eight 
accounts adjacent to the first square called on; that Is, he 
may not jump accross territortes. tf no sale Is made on the 
first call, he may, of course, call on the same account 
again durtng the same quarter. Furthermore, there {fs no 
limit to the number of salesmen who may call on the same 
account In one time perlod. Between quarters, salesmen may 
be moved to any accounts that the company wishes to cover 
during the next quarter, 

Each time a salesman makes a call, he 
has a certain fixed probability of making a sale. This 
chance of making a sale may be Increased In one of three 
ways or a combInatlion thereof: 


--A company may Intensify Its direct selling 
effort by having more than one salesman cover one 
account as described above. !n such a case, if 
the first salesman makes a sale, the second one 
may move to any adjolfning account for his calls. 


--A company may support the salesman's effort by 
advertising (see "Advertising the Product"). 


--A company may attempt to Improve its product by 
spending more money for a research and development 
effort (see "Research and Development"). 


Every salesman costs $10,000 to hIre and 
then $1000 per quarter In slary. (Since the product he will 
be selling Is a hlgh-price, compifcated unfit, It takes one 
year to train a salesman before he can be sent out [Into the 
fleld.) There Is a_ posstbility that a salesman will 
ee In which case the umpire Informs the company of this 

oss. 

The umptre should have the _ following 
Instructions for marketing: 


(1) Each pertod there Its a 5% chance of loss for 
each salesman. Move ahead on the random number table as 
many numbers as the company has salesmen; !f one or more of 
these numbers fs .05 or less, the company loses one or more 
salesmen. 


(2) In an urban market, allow two calls per 


Page 133 


quarter; in a rural market, only one call. 


(3) A salesman always has a 25% chance of making a 
sale. For each call, examine the next number on the random 
number table. If the number fs 25 or less, then a sale has 
been made; {ff ft Its 26 or more, no sale is made. 


Advertising the Product 


Product advertising’ In any quarter 
Increases the salesmen's chances of amking a sale. It 
covers only the region or regions (1,/1t,ltl, and !V on the 
game board) that the company desfgnates, and Is effective [n 
the current quarter only. Advertising costs $3000 per 
page, and a company may buy up to five pages of advertising 
In any region tn any quarter. 

Here are the umpIre's Instructions: 


For each sales call within the regfon(s) fn which 
the company has advertIised, go to the next number [n_ the 
random number table and determine whether or not there Is a 
sale according to the probabflittes In the followlIng table. 
If the number fs the same or below. the probability 
percentage, a sale Is made. 


Pages Amount Probability of a sale 
0 0 28% 

1 $3,000 29 

2 6,000 35 

3 9,000 k2 

h 12,000 48 

5 15,000 52 


Research and Development 


!{f a company can develop a superior 
product, [t gains a competitive advantage. Usually, 
research and development have to be fairly continuous to 
achleve a product Improvement, but a “crash program" may 
yield results [In a relatively short time. The minimum 
research effort per quarter costs $10,000, but a company may 
Invest more than that In multiples of $10,000. 

The umpire notifies the company 
Immediately when fts research and development program has 
produced results, and all units scheduled for production [n 
that quarter are considered to be equipped with the 
Improvement. To find out the extent to which customers wl! 
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prefer an Improved product, $5,000 of market research 
(obtatned from the umptres) Its needed. 

Of course, these ground rules can be 
altered to fit a company's sIituatton more closely--just as 
the ground rules for other aspects. of the Business 
Management Game can. A company manufacturing equipment for 
rallroads may well want to use different units of research 
expenditure than would a company making dies for plastic 
products. The length of tfme necessary to get results from 
research also varles greatly from company to company, as 
does the cost of research to measure customer reactions. to 
new products. These and other rules can--and In many cases 
should--be tallored to the realittes of the Industry. 

The umptres wilt tell a company as soon 
as a competing team Introduces an !mproved product [In the 
market. The players can then counter with a stepped-up 
marketing effort or a crash research and development 
program. 

If a company Is Interested In finding 
out the total Industry research and development expenditures 
for the past year, such Information fs avallable from the 
umpires for $1,000. 
In addition, the umptres should: 


(I) Matntatn a cumulative account of each 
company's expenses. After each break tn continulty (a 
quarter without any R & OD expenditures) and after each 
product Improvement, start the accumulation over agaltn. 


(2) Make approprtate revisions of the probability 
of Improvement. The cumulative dollar amount spent on 
research and development determines the chances a company 
has for obtaining a product Innovation. Examine the random 
number table; If the next number Is the same as or below the 
probability percentage, an Improvement Is achieved. 


Cumulative amount Probabiltty of Improvement 


$10,000 0% 
20,000 0 
30,000 0 
40,000 2 
50,000 | lb 
60,000 7 
70,000 11 
80,000 15 
90,000 18 


200,000 and over 20 
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(3) Whenever a company achieves an Improved 
product, Increase all Its sales probabIil!ty percentages by 
10. For example, If Company A has an Improved product, this 
Is the result: 


Probabllity of sale 


Old product 25% 
Improved product +10 
35% 


If Company A spends $6000 on advertising [n= one 
region and has an tmproved product, this Is the result In 
that regton: 


Probability of sale 
Old product with 


‘two pages of advertising 35% 
‘Improved product +10 
45% 


(4) As soon as all] three compantes have’ tmproved 
products on the market, cancel] the premium of 10 for all 
three, 
(5) If one company achleves two product 
Improvements before one or both of Its competitors have 
achleved any, Increase all fits sales probabl lity percentages 
by 20. 


Increasing Productton 


The I[nittfal plant which each company 
must bulld costs $150,000, and hdas a maximum throughput of 
5 units each quarter. From then on a company may add other 
production lines for $30,000 each. But each such $30,000 
Increment will Increase the maximum throughput by 5 . 

A company must pay for Increased 
capacity as soon as It decides to start construction. 
Construction time Is nine months (three time perlods), and 
only after completion may the first unlit be put Into “work 
In progress" for the new production line. The compantes 
are not allowed to sell or otherwise dispose of excess 
capacity. 

The total lead time In producing units 
In a company's plant ts sIx months. First, production fs 
scheduled, and this [Involves no financial outlay. Then Jn 
the next quarter unfts are put Into “work In progress" and 
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must be pald for. In the subsequent quarter these units 
come off the productton lIne , are added to Inventory, and 
may be sold. 


Total production cost contatns ai fixed 
cost and a varlable element. The fixed cost Is Incurred 
each quarter, regardiess of how many unfts are produced. At 
a maximum capacity of five units per quarter, the fixed cost 
Is $6000, and the variable cost per unit Is $3000. As 
capacity Is Increased by additfonal production ltnes, fixed 
costs rise and the varfable cost per unlit decreases. lf a 
company, prior to adding a line, wants to know the exact 
costs It will tncur at the next level of capacity, {It can 
get that Information from the umpfres' for $2000, but 
otherwise the umptres willl Inform the company what 
production costs are when the new line goes Into production. 

Units are added to Inventory at actual 
cost. When a unit Is sold, however, [ft Is deducted from 
Inventory at the average cost ( total Inventory Investment 
divided by number of units In Inventory). — 

The umptres should calculate the 
production costs at varlous capacIty levels as follows: 


Max. capacity Total unlit cost Fixed cost Variable cost 


per quarter per unfit 
5 $4,200 $6,000 $3,000 
10 3,600 14,400 2,200 
15 3,000 22,500 1,500 
20 2,400 28,800 1,000 
25 1,800 31,500 600 


Financtal Management 


The management of a company's avallable 
capital Is of critical Importance. Each company starts 
with $400,000 cap!tal’ and grow only through = relnvested 
earnings. Profitability wlll be [In direct relatfion to the 
skI11l with which the various parts of the business are kept 
In harmony with each other to achleve sound growth. 

The price per unft of product ts fixed 
at $10,000. When a sale Is made, accounts recefvable are 
Increased by the total amount of the sale, and on the game 
board an accounts recelvable symbol fs placed on the fifth 
space In the "accounts receftvable" column. Every quarter 
this symbol Is moved up one space unt!! after four quarters 
It reaches the top space and becomes cash. Competitive 
pressure In the Industry forces the extension of credit; 
hence the one year collection lag. 

If a company Is short of cash, accounts 
receivable may be factored to get cash Immediately. The 
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cost of doing this [fs 20% of the amount factored. 
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Appendtx 8B 


The following ts an MSL model of parts 
of the game (for one "regton") described tn Appendix A--as 
seen from the pofnt of view of a player wishing to 
Investigate the game and see the effects of varlous 
strategles. {tt Is presented here as an [llustration of the 


use of MSL, 


(#ACTIVITY HIRING 
(*PREREQUISTITES (*#PRESENT (1000 CASH))) 
(*SCHEDULE ON CALL) 
(#PRIORITY 2) 
(OUTPUT (SOME TRAINEE)) 
(*TAKES 0) 
) 


C*#ACTIVITY TRAINING 
(*PREREQUISITES 
CAND (#PRESENT (1000 CASH) ) 


C#PRESENT (SOME TRAINEE)))) 


(*TAKES 3) 
(*OUTPUT (SOME SALESMAN) ) 
) ; . 


C#ACTIVITY URBAN-CALL 
(*PREREQUISITES 
(AND (*#PRESENT (ASSIGNED 
(SOME SALESMAN) 


(SOME URBAN-CUSTOMER) ) 


(*PRESENT (500 CASH) ))) 
; (*TAKES .5) 


C#ACTIVITY RURAL-CALL 
(*PREREQUISITES 
(AND (#PRESENT (ASSIGNED 
(SOME SALESMAN) 


Page 139 


(SOME RURAL-CUSTOMER) )) 
(*PRESENT (1000 CASH)))) 
(*TAKES 1) 
) 


(*EVENT QUITTING 
(*CONDITIONS QUITTING-PROBABILITY) 
(*#ACTIVITIES (SALES-CALL) 
(*CANCEL) 
(*REMOVE (THAT SALESMAN) )) 
(*ACTIVITIES (TRAINING) 
(*CANCEL) 
(*REMOVE (THAT TRAINEE))) 
) 


(*ACTIVITY ADVERTISING 
(*PREREQUISITES (*PRESENT (3000 CASH) )) 
(*SCHEDULE ON CALL) 
(*QUTPUT (1 PAGE-OF-ADVERTISING) ) 
(*PRIORITY 3) 

) (*TAKES 1) 


(*ACTIVITY R&D 
(*PREREQUISITES (*PRESENT (10000 CASH))) 
(*TAKES 0) 
(*SCHEDULE ON CALL) 
(*OUTPUT (10000 R&D) ) 


(*EVENT PRODUCT-IMPROVEMENT 
(*CONDITIONS P-1-PROBABILITY) 
(#ACTIVITIES (R&D) 
) (*OUTPUT (1 PRODUCT-!MPROVEMENT) )) 


(*ACTIVITY PRODUCT-INITIATION 
(*PREREQUISITES (*PRESENT 
(1 PRODUCTION=LINE))) 
(*TAKES 1) 
(*OUTPUT (5 UNITS-IN-PROGRESS) ) 
) 


(*ACTIVITY PRODUCTION-COMPLETION 
(*PREREQUISITES (*#PRESENT 
(5 UNITS-!IN-PROGRESS) )) 
(*TAKES 1) 
(*OUTPUT (5 UNITS)) 
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) 


C*#ACTIVITY PRODUCTION-LINE-CONSTRUCTION 
(*PREREQUISITES (*#PRESENT (30000 CASH))) 
(*TAKES 3) . 
(*OUTPUT. (1 PRODUCTION-LINE)) 

) 


(#ACTIVITY FACTOR 
(*PREREQUISITES (#PRESENT (5000 A-R))) 
(*TAKES 0) 
C*QOUTPUT (4900 CASH) ) 

; (*SCHEDULE ON CALL) 


(*#EVENT SALE 
(*CONDITIONS SALES-PROBABILITY) 
(*ACTIVITIES (SALES-CALL) 
(*OUTPUT (10000 A-R))) 


(*FUNCTION SALES~PROBABILITY 
(*ARGUMENTS (PAGE-OF-ADVERTISING) ) 
(PRODUCT- IMPROVEMENT) ) 


(*RETURN 
(*SUM-UP 
25 
(AD-FUNCTION 
PAGE~OF-ADVERTISING) 
(TIMES .10 
5 PRODUCT~ IMPROVEMENT ) 


) 


(*FUNCTION AD-FUNCTION 
(*ARGUMENTS (PAGE-OF-ADVERTISING) ) 
(*#RETURN 
(*TABLE (PAGE-OF-ADVERTISING 
*RESULT) 
(0 0) (1 .08) (2 .10) (3 .17) 
(4h .23) (5 .27))) 


(*FUNCTION P-I PROBABILITY 
(*ARGUMENTS (R&D) ) 
(*RETURN (#TABLE (R&D *RESULT). 
CCLESSP R&D 40000) 0) (40000 .02) 
(50000 .04) (60000 .07) (70000 .11) 
(80000 .15) (90000 .18) (100000 .20) 
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